Итак, переходим к самому волнующему: под какой системой виртуализации будет работать наше облако? Простой поиск по интернету выдает такие разнообразные варианты, что прямо теряешься.

На самом деле ответ на этот простой: ставьте ту систему, специалисты по которой наиболее доступны вам. Что бы было у кого и с кого спрашивать.

Но это же не интересно и писать не о чем. Поэтому давайте я опишу личные впечатления о разных системах, которые можно заиспользовать.

Начну с моей любимой: OpenVZ (Коммерческая Virtuozzo). Самая скоростная система, которая по производительности легко уделывает все остальные. Имеет только один, зато толстый минус: позволяет внутри крутить только linux системы.

VMware. Самая старая, дорогая и поддерживаемая система. Есть бесплатные вариант ESXi, но возможностей у него кот наплакал. За деньги можно сделать систему абсолютно любого уровня. Основные минусы: цена и дикая нелюбовь к несертифицированному железу.

Xen. В коммерческом варианте – Citrix. В России я не видел нормальных внедрений, поэтому опыта у меня нет. Зато за рубежом одни из крупнейших провайдеров – Amazon и RackSpace использует именно его.

KVM. На самом деле это простой гипервизор, который есть в любом дистрибутиве линукса. Управляется исключительно из командной строки. Но благодаря поддержке гигантов, оброс различными системами управления и надстройками, которые позволяют конкурировать с системами на базе VMware. RedHat использует именно его.

Hyper-V. Продукт от микрософта и заточенный на работу с микрософтовскими же продуктами. Не так давно научился и linux крутить. Дорогой и пока глючный (ну или мне так везет).

VirtualBox. Бесплатная (для десктопа) виртуализация. Но если вам приходится много работать с Solaris или Oracle, то это единственный выбор.

В общем-то и все. Остальные системы пока в слишком зачаточном состоянии.

По функционалу все системы одинаковы. То есть заморачиваться вопросами «а умеет ли эта система что-то, что не умеет другая» абсолютно нет смысла: все необходимое есть. Разница в том, насколько удобно реализованы те или иные возможности.

К примеру, vmware имеет в комплекте конвертор, который позволяет с минимальными усилиями затащить в себя любую физическую машину, работающую под windows или linux. Она же единственная, кто дружит с OS X. Зато OpenVZ позволяет сделать так, чтобы файловая система (и сама виртуалка) была доступна с хост-машины без каких-либо проблем (и при необходимости наоборот). А KVM доступна на любой линукс-машине и позволяет с минимальными телодвижениями запустить образ от других систем. Ну и если у вас целиком вся инфраструктура на продуктах от микрософта, то с помощью Hyper-V вы мигрируете в облака без особых телодвижений.

В общем, крайне рекомендую перед окончательным выбором протестировать все системы под свои требования. Благо у всех систем есть триальные версии.

Хинт: нет никакой необходимости делать все на одной системе. Никто не мешает использовать несколько. Да, получится более сложная инфраструктура, но возможно более эффективная.
Ндас, как-то не очень маркетоидно получилось, зато про всех понемногу. Давайте лучше вернемся к приятному: планированию облака.

Если помните, то в предыдущей части вы разрисовывали связи и самое большое число связей получилось у сети и дисков. Вот эти две штуки и являются самыми больными частями в любом облаке. Любая неполадка или задержка вызывает вал проблем, который остановить очень сложно.

За что борются инженеры?

Во-первых, за скорость. Диск и сеть должны выдавать максимальные значения, дабы уменьшить простой процессоров на нодах.

Во-вторых, за число операций в секунду. Для дисков это зовется IOPS, для сети pps. Чем больше операций система может провернуть, тем меньше надо систем для обработки того же объема запросов.
Для этих значений принцип простой: чем больше, тем лучше. И поверьте, борьба за эти циферки идет жесточайшая. Их всегда не хватает. Вообще всегда.

Какие основные методы применяют?

Во-первых, разделение машин по функционалу. Скажем, у вас есть 10 веб-серверов. Предположим, что внутри каждого веб-сервера есть сам веб-сервер с каким-то движком (типа php или java) и SQL сервер. Простой вынос всех этих десяти маленьких SQL серверов на один (хорошо, на два, если нужна отказоустойчивость), но которому отдали их ресурсы, уже приведет к увеличению производительности.

Во-вторых, разделение потоков данных. Это тема в большинстве случаев сродни шаманству. Людей, которые понимают, где в обычных с виду систем могут возникать бутылочные горлышки и как их удалять, очень ценят.
Скажем же веб-сервер. Скажем, ему банально стало не хватать производительности. Поднять второй по каким-то причинам нельзя. Что делают в «лоб»? Обычно наращивают производительность. Скажем ставят SSD вместо обычных дисков. Да, производительность возрастет, но не сильно. Специалист «по горлышкам» придет и увидит, что у веб-сервера есть один поток на чтение, когда он отдает запрошенное, один поток на запись, когда он записывает в лог и еще один поток на запись, когда операционная система обновляет время последнего доступа к файлу. В результате достаточно отрубить время доступа (нафиг он на веб-сервере?) и поднять где-нибудь неподалеку сервер для сбора логов, как дисковой подсистеме отвечающей за веб-сервера резко полегчает: она будет работать только на чтение (и никто не мешает ей поставить RO, что бы еще больше облегчить жизнь). А у сервера логов только на запись. Все счастливы и довольны.

Есть и еще одно «шаманство». Обзывается разделением нагрузки по характеру. Скажем, у нас есть бухгалтерия и почта. Бухгалтерский сервер использует паттерн работы с диском «тут посмотрели, тут записали, тут посмотрели, тут записали» (упрощенно конечно). А почта «записали, посмотрели, посмотрели, посмотрели, записали». Причем временные интервалы и расстояния по диску между «посмотрели» и «записали» у обоих систем разные. В результате кэш, который обязан ускорять работу с диском, банально «загрязняется» и работает далеко не так эффективно, как мог бы.

Да, примеры немного наиграны, но и реальность просто отличается большим числом участвующих «переменных».

Ладно, хватит пугать, надо немного рассказать о типичных методах ускорения сети и дисков и встреченных мной (и совершенных тоже) ошибках.

Объединение линков. Как я писал выше, скорости никогда не хватает. Все сетевые штуки умеют объединять несколько сетевых линков в один. Скажем, у вас в сервере есть 4 порта, каждый на 1Гбит. И в коммутаторе тоже образовалось свободное место. Вы берете 4 патч-корда и соединяете их один-к-одному, включаете бондинг (объединяете их в один транк и так далее) и надеетесь, что в результате получите линк на 4Гбит. А в результате получаете тот же гигабит или чуть больше. Любой продвинутый сетевик уже понял, в чем засада. Для остальных: у бондинга много режимов и вариантов. И только некоторые предусматривают возможность распределение нагрузки по всем линкам.

Звезда – наше все. Это любимая и продвигаемая большинством модель построения сети. Если коротко, то все сетевые устройства подключаются к некой системе, которая уже и занимается передачей пакетов от одного устройства к другому. Просто, понятно и … дорого. Штуки, которые способны переваривать десятки и сотни гигабит (Откуда такие цифры? К примеру, одна виртуалка с бухгалтерией легко генерирует поток в гигабит к диску. Это всего-то 100 мегабайт в секунду. Обычный винт легко выдает) и при этом не становиться единой точкой отказа, стоят дорого. Для обычной сети эта модель практически идеальна. Но у облаков все немного по-другому. Скажем, есть очень большой поток данных между серверами хранения. Не к нодам, а тупо между собой. Для репликации, отказоустойчивости и все прочее. Более того, весь поток сосредоточен между серверами одной группы. Так зачем его гонять через коммутатор, когда гораздо выгодней зацепить сервера между собой прямыми линками? Просто из-за такого изменения топологии задержка в линке падает больше чем в 2 раза! И ведь точно такой же поток данных есть и между нодами …

Не все рэйды одинаково полезны. Скажем, нам нужно создать отказоустойчивый сервер хранения. Надо немного, буквально 20 терабайт. Что делает обычный, не «облачный» админ? Берет два сервера, пихает в каждый по шесть дисков на 4 терабайта, запихивает их в raid5 на отдельном контроллере, объединяет сервера и рапортует о готовности. В результате получается тормозной сторадж, который с трудом способен переварить 400-500 мегабайт данных в секунду. Что делает облачный админ? Берет десять дисков по паре терабайт, делает raid0 средствами операционной системы и затем объединяет сервера. Получившаяся шарманка легко берет планку гигабайт в секунду и не дохнет от на порядок больших IOPSов. Да и еще дешевле оказывается. Почему так получилось? Во-первых, облачный админ исключил лишний уровень отказоустойчивости. Зачем его дублировать на уровне дисков, когда он уже есть на уровне серверов? Во-вторых, raid0 сам по себе работает гораздо быстрее raid5, а тут вдобавок данные обрабатывают 10 дисков против 5 (и не надо ждать, пока raid5 завершит запись на всех дисках). И наконец, он освободил ресурсы процессора от расчета всяких контрольных сумм (если кто-то думает, что отдельные raid контроллеры работают быстрее обычного процессора, то он очень сильно заблуждается). Результат: выигрыш в скорости, выигрыш в IOPSах, выигрыш в деньгах! Сплошной профит!

SSD супротив памяти проигрывает всегда! Последнее время пошла мода ставить SSD для кеширования обычных HDD. Для десктопов это реально увеличивает скорость общения с диском. А вот с облаками эта штука практически не дает прироста. Просто из-за того, что слишком хорошо распределена нагрузка и редко когда в SSD попадает то, что можно закешировать. А ставить их пачками – дорого. Но почему-то редко кто додумывается поставить на сервер хранения не жалкие 16-32 гига памяти, а 256 или 512 и оттюнить операционку на максимальное использование кэша. Поверьте, эффект будет заметен невооружённым взглядом.

Но и это не все, над чем придется поломать голову. При переводе систем в облака крайне рекомендую заранее озаботиться в их установке в варианте, который позволяет масштабироваться с минимальными усилиями или исключить ненужное дублирование. Скажем, для систем на базе jboss можно почти расслабиться: он сам умеет находить аналогичные сервера и парралелить работу. Сервера с MySQL достаточно сразу поднимать в не в конфигурации standalone, а master: потом подцепить другой master или slave будет гораздо проще. Резервное копирование осуществлять не с помощью агентов изнутри каждой виртуалки, а централизовано, на сервере хранения.

Хинт: определить, что лишнее, довольно просто. Просто берете и мысленно ставите рядом еще одну точно такую же систему. Общие данные и там и там? Выносим на отдельную виртуалку/общий каталог на сторадже. Один и тот же сервис делает одну и ту же работу с одним набором данных? В отдельную виртуалку! Какой-то внешний сервис приходит регулярно за каким-то данными? Меняем схему, что бы не он приходил, а мы ему отправляли. И так далее и тому подобное.

В результате у вас должно получиться примерно в 3-4 раза больше «облачных» серверов, чем было «физических» сервисов. Но все сервера будут выполнять одну функцию, их будет легко собрать в группы по характеристикам и все они будут довольно легко масштабироваться.

Только заклинаю вас: сразу все определите правила для поименования, нумерации сети и документирования. Нет ничего хуже, чем обозревать сеть с server1, server2, test-server, lama, vanya (брать имена городов, животных, клички ничем не лучше). Поверьте, даже для небольшой компании со временем легко набирается сотня-другая виртуальных серверов. В имени сервера должно присутствовать как минимум указание на его функциональную сущность (например stor, node, app, web), его уникальный номер (хорошо если привязанный к его адресу в сети) и если необходимо, какой-либо другой признак (dev, ivan, test). А за отход от правил тут же и немедленно бить чем угодно. Но еще лучше помогает тупо удаление сервера: второй раз никто такую ошибку обычно не допускает.

И тогда любой при взгляде на stor25fast сможет сказать, что это сервер хранения для требовательных к ресурсам задач с адресом 10.0.0.25, a web40-test-ivan – тестовая машинка с веб-сервером, поднятая Иваном и имеющая адрес 172.16.0.40. Думаю, смысл понятен.

Думаю, я достаточно загрузил вас. Пора немного прерваться.

И да, я опять спер картинку

Данный текст я решил написать в расчете на ИТшников, которые уже задумались про перевод своей инфраструктуры в «облака» и теперь думают, как же это сделать. На мой взгляд, в интернете слишком много уделяется внимания тому, как надо покупать «облака» (дальше буду без кавычек), а не тому, как их использовать, создавать или как они устроены. Дескать, это сложная наука, подвластная только крутым специалистам с кучей дипломов. Ну или интеграторам с такими специалистами в штате. Стоимость подобных облаков обычно получается какая-то негуманная. А если упомянуть про про bigdata, DWH и прочие слова из буклетиков, то к ценнику добавляется нолик-другой.

На самом деле, все не так страшно и я попытаюсь доказать вам это. Может быть даже с примерами и рисуночками.

И да, обычное предупреждение: я рассказываю на основе своего опыта и могу быть неправым от и до. Но вроде созданные системы выполняют свои задачи и жужжат совершенно по делу.

Для начала надо определиться, что же такое облако и с чем его можно есть.

Для ИТшников это куча физических серверов, которые с помощью какой-то системы крутят много сервисов. Сервисам выделяются ресурсы по необходимости или по требованию. Сервисы могут мигрировать с сервера на сервер, размножаться или уничтожаться. Или говоря другими словами, обычный набор железок, который можно встретить в любой серверной.

Для обычных же людей это некая сущность, которая предоставляет им сервисы по формуле «дешевле, быстрее, надежнее: выбери два из трех». Опять ничего нового.

Всякие слова про масштабируемость, отказоустойчивость и прочее можно оставить маркетингу. Методы реализации этого великолепия известны очень давно и облака ничего нового в этом плане не открыли, а просто сильно упростили.

Как-то грустно получается, не находите? Почему же облака так стали популярны? Дело в том, что появились новые методы использования доступных мощностей. И как раз они основаны на сильном упрощении процесса обеспечения тех самых «масштабируемостей», «отказоустойчивостей» и прочего.
В итоге грань между «отказоустойчивым кластером» (масло маслянное, да) и «облаком» получилась … ну очень тонкой. Поэтому предлагаю оставить теологические споры диванным аналитикам и перейти к практике.

Что можно получить от облака?
– Снижение расходов на обслуживание бизнеса. Как прямых, вроде стоимости серверов, так и косвенных, в виде ускорения каких-либо бизнес-процессов.
– Увеличение доступности сервисов. Выйти на «5 девяток» по-прежнему дорого, но гораздо дешевле, чем это было лет пять назад.
– Открытие новых возможностей для бизнеса. Звучит слишком рекламно, но это реально так. Новые технологии реально дают такие возможности, даже заикание о которых раньше приводило к кручению пальцем у виска.

Остальные преимущества в принципе либо укладываются в эти пункты, либо проистекают из них. Давайте я попробую раскрыть эти пункты на примере наиболее распространенных решений.

Для начала про повышение надежности и снижение стоимости. Откуда это получается? Во-первых, обслуживать настроенные однотипно сервера гораздо проще, чем обычный зоопарк. Одни и те же версии программного обеспечения, одно и то же железо. Это дает выигрыш как во времени работы инженеров, так и позволяет получать скидки от вендоров. Во-вторых, возможность вывести любой сервер из кластера для обслуживания. Просто даем команду системе виртуализации убрать с него все сервисы и спокойно занимаемся необходимым. Тем более такую команду может дать и система мониторинга в случае превышения каких-либо значений типа температуры процессора или скорости вращения вентиляторов. И в-третьих, система мониторинга может дать и другую команду: добавить ресурсов «задыхающемуся» сервису. Думаю, любой ИТшник сразу же найдет кучу применений этим возможностям.

«Публичные» и «гибридные» облака благодаря этому и обладают возможностью на время получить буквально на час огромные ресурсы, за которые в обычном случае пришлось заплатить очень дорого. Например, я знаю рекламные агентства, которые в облаке арендуют мощности для обсчета роликов.

Вот я тут упомянул публичные и гибридные облака. Чем они отличаются? Публичное облако – это такое облако, все сервисы которого крутятся у провайдера. Гибридное – это «размазанное» по своим и провайдерским мощностям.

Теперь немного про популярные слова, которые связаны с облаками. И которые связывают с преимуществами для бизнеса.

Вот скажем bigdata. Что это? Я встречал определения типа «это то, для обработки чего не хватит даже самого мощного компьютера» и «петабайты данных». Я сторонник другого, более крамольного определения.Bigdata – это те данные, которые у нас уже есть, но мы не знаем, что с ними можно сделать. А потерять не охота. У кого-то это будет мегатонны логов пользователей, у кого-то куча данных с датчиков а у кого-то это будет жалкая пара терабайт картинок. И вот облака дают возможность как-то хранить и по возможности обрабатывать эти данные. При этом бигдачность системы вовсе не характеризуется объемом обрабатываемых данных. Есть системы, где обрабатываются буквально гигабайты данных, но эти гигабайты легко грузят сотни серверов. В общем, красивое слово.

VDI. Или Virtual Desktop Infrastructure. Развитие идеи терминальных серверов, только с предоставлением пользователю своей виртуальной машины. Шикарно ложится на облака, особенно в случае применения однотипных АРМов и поэтому в последнее время развивается очень сильно.

DWH или Data WareHouse. Еще одно общее слово. Для кого-то это хранилище кучи файлов, кто-то хранит всякие таблички. Говоря кратко, это то место, куда бегают всякие система анализа и отчетов за данными. Данные там собираются из разных источников, приводятся к общем знаменателям, группируются и так далее и тому подобное. По понятным причинам DWH очень любят всякие финансовые компании.

Ладно, хватит красивых слов, тем более, что интересующиеся могут спокойно напрячь поисковик и начитаться по любому интересующемуся термину. Пойдем практиковаться.

Планируем облако.

Что надо сделать в самом начале? В самом начале надо взять за шкирку вашего системного аналитика … как нету аналитика? Тогда берете за шкирку себя и начинаете описывать и считать.

Берете каждый сервис в вашей инфраструктуре и все обдумав, отвечаете на следующие вопросы:

– Время работы сервиса. Круглосуточно, ночью, днем в рабочие часы. Бухгалтерия ночью не работает, а веб-сайт должен быть доступен круглосуточно.

– Доступность сервиса. Может ли он делать паузы во время работы? Скажем на 5 минут? Телефония должна работать всегда, а вот резервное копирование может и постоять на паузе.

– Критичность сервиса. Если он «упадет», как сильно это повлияет на бизнес? Сравните бухгалтерию во время сдачи отчета и внутренний портал. Если добудете цифры в духе «простой 5 минут – 100500 рублей» или «день простоя – штраф в мульен», то вообще отлично. Хинт: заручитесь одобрением финансистов и бухгалтеров: они тают, когда ИТшники их спрашивают про их тяжелую долю и пытаются ее облегчить.

– Ресурсные требования по времени. Телефония требует ресурсы пиками и очень не любит, когда ей недодают ресурсов вовремя этого пика. А тот же веб-сервер толерантен к таким проблемам.

– Просто ресурсные требования. Сколько дисков-процессоров-сети надо сервису.

– Сложность обслуживания? Сколько ИТшников в среднем требуется для обслуживания этого сервиса. Стоимость ИТшника?

– Есть ли возможность прогнозировать нагрузку? Для веб-сайта – нет, а для той же системы резервного копирования – запросто.

– Зависимость сервиса. Скажем, бухгалтерия не выживет на одном офисе без бухгалтерской системы, ей будет очень плохо без сервиса печати, чуть полегче без телефонов и ей абсолютно будет начихать на веб-сайт. Но все умрет без работающей системы хранения данных.

– Возможность вынести сервис наружу. Веб-сайт и почтовые системы – почему бы и нет? Бухгалтерию – убьют.

– Уровень масштабирования в зависимости от роста компании. Веб-сайту пофиг, сколько у вас сотрудников, а той же VDI или почтовой системе – нет.

– Сложность масштабирования системы в зависимости от нагрузки. Веб-сайты обычно довольно легко сделать масштабируемыми, а вот телефонию без бутылки не отмасштабируешь. Тут очень хорошо подумать, а какие функции этого сервиса можно отдать наружу.

При этом очень желательно максимально детализировать сервисы. Скажем типичный веб сервис на самом деле состоит из кеширующего сервера, веб-сервера, сервера базы данных и сервера хранения данных. Чем более высокой будет детализация, тем в дальнейшем будет проще.

Это очень нудная, сложная и муторная работа (хотя и должна быть сделана в рамках ITIL/ITSM). Но в качестве утешения я вам обещаю, что вовремя или после процесса вы обнаружите кучу интересных вещей, которые были раньше скрыты.

Кстати, рекомендую сразу же вооружиться чем-нибудь типа visio (или хотя бы листочком с бумагой, но лучше visio) и сразу зарисовывать получаемые ответы. Я рисовать не буду, ибо мне попросту жалко своего времени, ибо это работа огромная и впустую ее делать лень.

Но на данном этапе я повангую и скажу сразу: больше всего линий пойдут к двум сервисам – сервису передачи данных (он же обычно обзывается «локалкой») и к сервису хранения данных (он же жесткий диск, он же файлопомойка, в некоторых случаях это будет NAS).

Следующим по числу «использований» будет сервер баз данных. Но большая часть будет с двумя линиями – к серверу приложений и к хранилищу данных. Зато этих серверов баз данных будет много. Веб-сервер, бухгалтерия, мониторинг, чертлысый – и везде какой-нибудь да серверок будет.

В принципе, уже полученную схему можно распечатывать и вешать на стенку. Непосвященные люди будут впечатляться и водить пальцами по бумаге, отслеживая линии.

Теперь настала пора взять в руки краски и любым приятным способом раскрасить сервера по критичности для бизнеса. При этом рекомендую брать как минимум два цвета: один для «критичный всегда», а второй для «критичный только в рабочее время». Скажу сразу, если у вас получилось, что все сервисы «критичные всегда», то что-то вы не так сделали. Весь мой опыт говорит о том, что так не бывает. Понижайте градус критичности.

Затем закрашивайте тем же цветом те сервисы, от которых зависит данный сервис. Скажем, если вы пометили, что телефония у вас критичная, то следом должны стать критичными «интернет», «локалка», «фаерволл», «сервер данных о пользователях» и стораджи, на которых все это лежит. Ведь без любого из этих сервисов телефония попросту не будет работать. Скажем, отнимаем интернет или фаерволл – перестаем принимать звонки из внешнего мира. Убираем локалку – пользователи перестанут получать звонки. При закраске необходимо строго соблюдать уровень критичности по повышению – если сервис «критичен всегда», то он не может быть перекрашен или зависим от «критичен только в рабочее время».

Данный процесс очень напоминает настройку сервисов в системе мониторинга или для change management из ITSM, поэтому эта работа или уже сделана или должна быть сделана. Поэтому в любом случае работа не будет сделана впустую.

Следующим шагом необходимо изучить у критичных сервисов механизм масштабирования и его стоимость. Где-то будет все просто: добавляем кучку однотипных сервисов и все будет в порядке. А где-то дешевле ограничиться добавлением аппаратных ресурсов. Тут можно покрасить разным цветом рамки или еще как-нибудь разделить «хорошо масштабируемые» от «плохо».

И я очень надеюсь, что вы использовали visio или что-то подобное. Для понимания текущей ситуации очень полезно сгруппировать сервера по критичности/доступности/расположению (как вам больше нужно).

И наконец, последний шаг. Считаем себестоимость каждого сервиса. Скажем, сколько стоит нам веб-сервер сейчас? А если его в локальный кластер? А сколько будет стоить, если его унести на арендованный у провайдера сервер? А если под него купить облако? Есть ли загружаемые с веб-сервера большие файлы, под которые дешевле будет купить сервис CDN? Есть ли разница в стоимости лицензий для «standalone» и «cloud/terminal»? Если мы уменьшим время простоя, то сколько сэкономим?

В результате у вас получится большая портянка, по которой будет сразу понятно, какой сервис выгодно тащить в облако, для какого лучше построить локальный кластер (и какими ресурсами он должен обладать), а какие реализовать по остаточному принципу или вообще оставить на отдельных машинах.

Теперь необходимо причесать картинку и полученную табличку, чтобы получить практически непотопляемые аргументы для любого совета директоров/ акционеров/ финансистов/ ещекого. Эти люди по роду своей деятельности очень любят картинки, которые подкреплены реальными цифрами.

Наиболее внимательные сразу отметят один очень важный момент, который вроде нигде не упомянут: а как выбирать систему виртуализации? Ведь ее тоже необходимо закладывать в бюджет.

Скажу сразу, выбирать систему виртуализации еще рано, в следующей части будем. Вы для начала докажите себе и владеющим деньгами людям, что это вообще выгодно будет. Для предварительных расчетов можете смело ставить стоимость системы виртуализации в 300 баксов на один железный сервер. Этого при необходимости хватит на корпоративную и пальцатую VMware, но скорее всего можно будет обойтись гораздо меньшими деньгами. Лучше побольше заложите на инженеров. Чем он будет более «продвинутей», тем больше шансов, что у вас все взлетит.

И да, картинку спер из интернета. Автора не знаю, а то бы написал.

Итак, несмотря на мои страшилки в предыдущих постах, вы все-таки решили использовать “облака” в своей деятельности. Хоть чуть-чуть, но использовать. Как выбрать то, что стоит нести в облака, а что не стоит?

Для этого есть несколько методик, ниже я попробую объяснить наиболее … подходящие, что ли.

Методика первая, пусть будет “секрет полишинеля”. В соответствии с ней в облако может отправиться любой сервис, который использует данные из внешнего мира или отдает их туда. Под это определение прекрасно подходят такие сервисы, как электронная почта, телефония и веб-сайт.

“Ну ладно, веб-сайт понятно, а как же с почтой и телефоном? Их смогут читать/слушать чужие люди?”. Да, при наличии соответствующих навыков или всяких судебных решений их и так будут читать и слушать чужие люди. Если говорить про телефон, то на операторе (тот, который выдал вам телефонный номер) уже стоит система, позволяющая прослушивать все телефонные разговоры, проходящие через него. А что касается внутренних переговоров, то они в большинстве случаев абсолютно никому не интересны и способны забить любой сервер. То же самое касается и почты. Буквально пара команд у провайдера, который предоставляет вам доступ в интернет, как весь ваш трафик оказывается у него как на ладони. И не обольщайтесь насчет страшных слов SSL/TLS – в подавляющем большинстве случаев все вскрывается так же легко, особенно при наличии административного ресурса. Правда, вынужден добавить ложку меда: по разговорам со знакомыми, такое используют очень редко, ибо во-первых, принцип “неуловимого джо” никто не отменял, а во-вторых, через налоговую сделать все необходимое гораздо проще.

Следующая методика “берите все, что нам негоже”. Тут в облака отправляются данные, которые вам не нужны прямо сейчас или которые нужны всем. Тут главное установить принцип, насколько эти данные вам не нужны. Скажем, данные от систем резервного копирования вам именно сейчас не нужны, занимают много места и хранение их рядом с резервируемыми системами прямо противоречит всем нормам. Так зашифруйте их посильнее и пусть лежат где-нибудь в Америке. Что касается данных которые нужны всем: зачем устраивать на своем сервере каталог “для скачки”? Ролики, дистрибутивы программ и прочие подобные штуки с удовольствием примут к себе системы CDN. Будут довольные и пользователи, которые будут скачивать необходимое им быстро и Вы, так как канал до вас (или вашего сервера) не будет загружаться.

И наконец, в облака удобно/выгодно отправлять то, что относится ИТшному понятию R&D. Говоря кратко, то, что запускается “на посмотреть”, меняется по двадцать раз на дню и наполняется тестовыми или сильно устаревшими данными.

Теперь про данные, которые нельзя отправлять в облака. Понятное дело, Вы сами сможете определить список того, что позволить прочитать другим нельзя. У кого-то это будет бухгалтерия, у кого-то данные о техпроцессе, в общем, у каждого свое. Тут надо просто садиться и разбираться.

Но (по крайней мере для России) есть одна категория, которую нельзя отправить в “облако”: персональные данные. Говоря простыми словами туда попадает все от паспортных данных и места проживания и до всяких медицинских анализов и выписок. Нельзя не потому что не получится, а потому что “атата, если обнаружат”: ни одно известное мне “облако” не использует сертифицированных средств защиты информации. Вроде в России потихоньку начали появляться провайдеры, которые обеспечивают обработку персональных данных, но там от облаков только название, да и ресурсы, которые они могут предоставить, вызывают лишь недоумение.

А теперь абзац неприкрытой рекламы меня любимого: мне нравятся “облака” и я готов совершенно бесплатно (конечно, не откажусь и от оплаты, если предложите 🙂 ) поконсультировать/помочь/рассказать как сделать по поводу “облаков”. Просто из любви к теме. Я не связан с каким-либо провайдером или сервисом “облаков” или производителем систем виртуализции, поэтому мне абсолютно начхать на маркетинговые заморочки. Пишите письма на multik@multik.org, в skype пользователю kiltum или оставляйте комменты.

В прошлый раз я обещал на пальцах показать, что облака дороже, но они дешевле. В принципе я уже писал про это, но это было давно и не правда.

Наверняка вы уже задумывались о использовании “облаков” в своем бизнесе, но простые расчеты на калькуляторе и консультации с ИТшниками неизменно приводили к обескураживающим результатам: стоимость аналогичного, но “облачного” сервиса неизменно оказывалась в 1,5-2 раза выше. Как же так? Ведь вон сколько компаний использует облака в своей работе и рапортуют о снижении расходов … А тут ИТшники опять начинают свою вечную волынку про недостаток серверов … Что делать?

Что бы не быть голословным, возьмем для примера небольшую компанию, чья инфраструктура построена на классических принципах. Давайте посчитаем, сколько серверов надо. Ну и заодно прикинем на пальцах стоимость каждой железки.

1. Фаирволл. Он же брэндмауэр. Штука, которая выпускает вас в интернет, фильтрует лишнее и иногда служит HR-инструментом под названием “на какие сайты ходят сотрудники”. Хватит 50 тыщ.
2. Почтовый сервер. Без почты нынче никуда. Тут лучше заложить где-то в районе 100 тыщ.
3. Веб-сервер. Сайтик обычно много нагрузки не требует, поэтому тоже 50.
4. Сервер телефонии. Положим те же 50 тыщ.
5. Сервер бухгалтерии. Бухгалтера люди нервные, поэтому 100 тыщ и не надо экономить.
6. Файлопомойка. Сотрудникам надо файликами обмениваться. Возлагать это на почту – моветон. Тыщ 80 надо.
7. Резервное копирование. Есть компании, где уже теряли данные, а есть, где еще только будут. Тыщ 100.

Для начала хватит. Конечно, в реальности часть функций обычно объединяется на одном сервере, но у нас админ печется о безопасности, поэтому старается разнести все. Ну и в разных компаниях добавляются другие сервера: для разработки, тестирования и прочих штук. Но я их учитывать не буду.

Итого получается в районе 550 тысяч рублей. Эти 7 коробок жрут электричество, требуют охлаждения, запасных частей и квалифицированного присмотра. Через некоторое время их мощности начинает не хватать и начинаются узаконенные репресии пользователй в духе “более 500 мегабайт в почтовом ящике не хранить” и “бухгалтерия тормозит, потому что в сервере винт сдох” (хорошо, что тормозит. у некоторых просто падает). Знакомо?

Что делать? Бизнес растет, но на одних серверах разориться же можно … И тут в дело вступает хороший, качественный ИТшник. Срываю так сказать, покровы. Для начала: одиночные сервера никогда не загружены на 100%. Из-за разных там особенностей больше 60-70% нагрузку поднимать попросту нельзя: будет все ломаться.

Сначала составляют список серверов (у нас он выше) и характер их загрузки. Например, сервер бухгалтерии и файлопомойка ночью не используется. А вот сервер резервного копирования наоборот, ночью загружен по самое выше некуда. А вот почта и телефония ночью тоже не загружены, но работать должны всегда.

Отсюда вытекает вполне логичное предложение: почему бы серверу резервного копирования не поделиться днем своими ресурсами? А серверу бухгалтерии и файлопомойки ночью? С использованием современных технологий – легко.

Сам процесс объединения стайки серверов в “облако” я пропущу. Вам это во-первых попросту неинтересно, а во-вторых, там слишком много нюансов, описанию которых пришлось бы посвятить много места.

В общем, сразу перескочу к моменту, когда из уголка админа раздаются невнятные, но несомненно радостные возгласы. Пропущу так же сложный процесс ломки мышления того же админа, пока он осознает, какие возможности он получил в свои руки.

Вам же главное знать то, что у вас теперь есть свое “облако”. Персональное, частное – называйте как хотите.

Что вы получаете?

– Возможность продать один-другой сервер. Подчеркиваю – возможность (ИТшники просто так не выпустят из своих рук 🙂 ). Ибо если одиночные сервера нельзя грузить на 100%, то в “облаке” вполне.
– Более высокую доступность серверов. Теперь в случае поломки одного из “железных” серверов есть возможность попросить “пододвинуться” другие, пусть и за счет уменьшения скорости работы.
– Возможность отдавать более мощный сервер (у нас же сервера не одинаковые изначально) на более необходимую сейчас работу. Скажем, днем самый мощный сервер будет помогать процессу сдачи бухгалтерского отчета, а ночью обрабатывать данные для системы резервного копирования.
– Более разумно распределять нагрузку. Скажем, отобрать ночью у почтового сервера ресурсы процессора в пользу других. Пусть письмо ходит не 1-2 секунды, как днем, а 10-20. Кому какая разница?

А теперь о более приятном. Если делать подобное с “нуля”, то более высокую производительность и бОльший запас по мощности всего комплекса можно получить с помощью пары серверов, каждый из которых стоит по 200тр. И эти серверы будут жрать меньше электричества, меньше греть окружающую среду и требовать меньший уход. 150 тысяч экономии прямо “в лоб”!

Но это “частное облако”. Как же можно заработать или сократить расходы с помощью публичных облаков?

Для начала можно легко увеличить безопасность вашего бизнеса. Не знаю как в других странах, но в России до сих пор не изжили “изъятие вещественных доказательств”. С одной стороны, счет не заблокирован и на нем есть деньги, а с другой – все данные остались на тех самых “вещественных доказательствах”. Вот для примера бухгалтерия. Объемы базы данных очень редко превышают еденицы гигабайт. Вот возьмите и дайте задачу, что бы система резервного копирования попутно заливала данные еще и туда. Для безопасности – хорошо зашифрованными. Сейчас стоимость хранения одного гигабайта на S3 – $0.03 в месяц. Да, я не ошибся – три цента за гигабайт в месяц. Добраться до архивов можно будет с любого компьютера, подключенного к интернету, а уж что с ними делать – дело ваше. Сравните со стоимостью хранения подобного где-нибудь на стороне “обычным” способом.

Затем рассмотрите свои бизнес-процессы и выделите те, которые требуют непродолжительных, но больших компьютерных ресурсов. Скажем, в каком-нибудь рекламном агенстве это может быть процесс рендеринга роликов. Покупать для этого отдельный мощный сервер, который будет 90% времени пинать балду – не выгодно. А без него никак. Куда лучше за $3 в час арендовать гораздо более мощный сервер в облаке и использовать его только тогда, когда надо. И кто мешает арендовать не один сервер, если роликов много?

Надо изредка рассылать большие объемы писем (и которые ни разу не спам)? Вон, SES берется доставить со всеми заморочками тысячу писем за 10 центов. Стоимость обычного почтового сервера, способного переварить хотя бы 20-30 тысяч писем за час, предлагаю узнать самостоятельно.

И так далее и тому подобное. Везде, где требуются большие объемы, гораздо дешевле воспользоваться мощностями гигантов, чем пытаться сделать свое и на коленке.

И наконец, можно заранее подготовиться к приятным, но внезапным неожиданностями. Для примера можно подготовить все необходимое, что бы ваш веб-сайт смог выдержать любой поток посетителей. В обычные времена ваш веб-сайт крутится у вас за стенкой. Но стоит возрасти нагрузке (скажем, отдел рекламы провел успешную компанию), как ваш веб-сайт сначала переездет к провайдеру (что бы не загружать ваш канал в интернет), а при дальнейшем повышении нагрузки начнет поднимать у провайдера свои копии. И так до тех пор, пока весь поток посетителей не схлынет. Схлынул – сайт вернулся в родные пенаты. Не верьте мне, просто возьмите калькулятор в руки и подсчитайте стоимость подобного решения. Если у вас подобные случаи случаются регулярно, то вы будете очень обрадованы открывшимися возможностями.

И подобных возможностей в каждой компании – уйма. Честно.

Если все так хорошо, то почему все так плохо? Во всем этом есть одна большая ложка дегтя: без квалифицированных специалистов подобное реализовать нельзя. В смысле реализовать можно, но вы скорее потеряете деньги, чем сэкономите. И пока технологии “молодые”, нет никаких сертификатов, лицензий и прочих документов, свидетельствующих о том, что тот или иной ИТшник умеет “нырять” в облака и что более важно, “выныривать” из них …

А таких – мало.

… или о облаках простыми словами.

Покупайте наших слонов, теперь и в облаках! Самые облачные облака по выгодным тарифам!

Такое или примерное такое сейчас можно увидеть и услышать в любой рекламе услуг, связанных с компьютерами. Что же такое облака и чего с ними можно делать?

Для начала маленький экскурс в историю. Давным-давно компьютеры умели выполнять только одну задачу за раз. И если он начинал считать, сколько будет 2+2, то нипочем не хотел останавливаться. Потом компьютеры научили делать сразу несколько задач. Они могли одновременно считать сколько будет 2+2 и спрашивать у пользователя, сколько ему лет. Потихоньку увеличивая мощность компьютеров дошли до того, что один мощный компьютер мог представляться для окружающих кучей слабых. Ведь для очень многих задач куча слабых компьютеров гораздо удобней и выгодней одного, но очень мощного.

Но тут пришли продавцы и маркетологи. Первым надо было увеличить продажи, а вторые помогали первым, ведь им тоже перепадал кусок пирога.

Поначалу шаги было очень осторожными. Практически все шло под лозунгом “сократи расходы на сервера”. Ведь в самом деле, поставить и обслуживать один мощный сервер гораздо дешевле, чем кучку маленьких. Тут и стали называть эти маленькие сервера виртуальными. Ведь их нельзя пощупать, но они есть. Постепенно технологии дошли до того, что стало возможно объединять мощные сервера между собой так, что они могли “делиться” с соседями виртуальными серверами без их остановки. И на всех схемах сети такая конструкция обозначалась облаком. Типа мы знаем, что сервер там, но детали реализации от нас скрыты.

Ушлые маркетологи мгновенно раскопали ассоциацию и начали толкать “облака” в массы. В результате вышеописанное (несколько мощных серверов, которые стоят в серверной у вас за стенкой) стали называть “частное облако” или private cloud.

Тут же появились провайдеры, которые стали предлагать “облака” для всех страждущих. Такие облака стали называть “публичными облаками” или public cloud. Услуга довольно быстро стала популярной: ведь большинству людей не нужны для своих задач мощные компьютеры, а провайдерам очень дорого обслуживать обычные слабые сервера.

Следующим появились на свет “гибридные облака”. Это когда часть виртуальных серверов работает в серверной за стенкой, а часть – у провайдера. А для вас – ну абсолютно никакой разницы, где они размещены. Вы работаете с ними одинаково во всех случаях.

Больше всего “облакам” радовались ИТшники. Благодаря “облакам” у них исчезло очень много нудной работы по обслуживанию серверов … Конечно, появилось много другой работы, но это тема уже для другой статьи.

Итак, в чем же основное преимущество облаков?

– Снижение расходов на серверный парк. По моим прикидкам, переход с классической схемы (один сервис – один сервер) на облачную (много серверов – много сервисов) дает экономию примерно в 20-30% просто от самого факта использования.
– Снижение времени простоя. Теперь для обслуживания “железного” сервера нет необходимости останавливать работу размещенных на нем сервисов.
– Резкое ускорение специфических для ИТ задач. Поднять новый сервер или скопировать работающий – дело минут, но никак не часов.
– Возможность при наличии соответствующих навыков кратковременно и очень резко увеличивать мощность какого-либо сервиса.

Вот за эту особенность и ухватились в очередной раз маркетологи. И как обычно, выкинув самые значимые слова (я про навыки), ринулись на следующий виток. Необходимость как-то разделять “облака” их надолго не остановила и они придумали новые слова.

“Старые” облака (провайдер вам предоставляет один или несколько серверов, возможно объединяя их в одну сеть с вашей) стали называть IaaS (Infrastructure as a service). Инфраструктура как сервис. Легко понимаемая всеми ИТшниками модель. Яркий пример – Amazon

Вон та возможность резко увеличивать мощность (повторюсь, при наличии навыков!) привела к следующему варианту облаков: PaaS (Platform as a service). Платформа как сервис. Пример – Azure. Суть простая. Берет провайдер толковых спецов, которые настраивают какой-либо сервис как надо. А потом продает этот сервис вам. Скажем, у вас есть веб-сайт, на который приходит 1000 человек в день. Ваши маркетологи, продавцы и прочие товарищи что-то такое замутили, что к вам внезапно пришло 100000 человек. Обычно веб-сайт в таких случаях тупо умирает под нагрузкой. В случае PaaS правильно настроенный сервис начинает поднимать для внезапно свалившейся нагрузки еще сервера. Десять, сто, тыщу. В общем пока не переварит весь поток. А потом точно так же берет и “убивает” ставшие ненужными сервера. В итоге все довольны: пользователи увидели ваш сайт, а не сообщение о недоступности, вы получили новые заказы, а провайдер – деньги.

Очень это понравилось маркетологам и они придумали SaaS (Software as a service) или программа как сервис. Оно очень похоже на PaaS, но про отдельный сервис. Скажем, вам нужен почтовый сервер. Можно сказать админу, он купит сервер, настроит его … А можно пойти к провайдеру и купить доступ к его почтовому серверу. Если у вас в компании 100 человек, так и купите кусочек провайдерского сервера на 100 человек. А провайдер пусть уже сам мучается с антивирусами, антиспамами и прочей фигней. Яркий пример – Office 365.

Но тут внезапно обнаружилось, что SaaS один-в-один повторяет то, что предлагается уже много лет. В самом деле, купить кусок сервиса можно было очень давно. И Вам совершенно безразлично, на каких там технологиях крутится.

Думаете это кого-то остановило? Неа, просто стали продавать старое под новым соусом.

И для резюме нужно подвести итоги. Сравним их с привычной всем “своей серверой”

Преимущества:
– Быстрота развертывания. При наличии денег на карточке можно получить полностью готовый сервер или сервис за десятки минут. Причем в стране на выбор.
– Более высокая доступность. У провайдеров просто больше возможностей это обеспечить.
(ТОЛЬКО для частных облаков) – Более низкая стоимость обслуживания

Недостатки:
– Более высокая стоимость обслуживания. На данный момент – в 1,5-2 раза дороже. За тренд надо платить.
(для всех КРОМЕ частных облаков) – Полная потеря контроля за вашими данными. Что бы там не писали маркетологи в пресс-релизах и зазывалках, данные из облака очень легко (по сравнению с классической схемой) могут быть взяты без возможности какого-либо контроля с вашей стороны. Люди, которые имеют доступ к физическим серверам, всего лишь люди.

Тут обычно возникает мысль про то, что я (в смысле автор) ничего не понимаю. Ведь если “облака” стоят дороже, то почему ими пользуются? Люди же не настолько глупые …

Но где можно “выиграть в облаках”, я напишу в другой раз. Вдруг никому не надо и я только зря клавиатуру терзал? 🙂

… или мой опыт, про который не напишут в книжках. Вторая часть

Айтишник – это прежде всего тонкая и чувствительная натура, а уже потом грязно матерящийся скунс.

Давным-давно существует стандартная структура управления: наверху начальник, а внизу его подчиненные. Подчиненные тоже могут быть начальниками и так далее по нисходящей. Всё всем известно и понятно. Однако окружающие не стоят на месте и пытаются все время придумать нечто новое. Всякие agile, scrum и прочие красиво звучащие штуки. Одной из такой штук стало матричное управление.

Всякие умные слова можно прочитать … ну скажем, на e-xecutive.

Согласитесь же, круто все? Наша компания самая прогрессивная и вообще практически мгновенно адаптируется к изменяющимся условиям!

Однако … в общем, опять перейду на личности. В общем, в свое время я совершил две ошибки: во-первых, позволил этому зародиться в компании. Не подумал, пропустил, не смог доказать. Уже не важно. А во-вторых, вместо активного разъяснения я выбрал линию активного противодействия. Думаю, многие вспомнят совещания, где я прямым текстом говорил, что я дал команду подчиненным всех приходящих к ним с вопросами/задачами/еще чем посылать “на х.й”. Вообще всех. И все претензии отправлять мне. И мне было абсолютно пофиг на то, что айтишников ругали. Хорошо еще, что еще было кого ругать …

Что бы понять, почему я так возбудился, необходимо сделать небольшой экскурс в внутренности айтишника. Инженера, архитектора, черта лысого. Не важно.

Айтишник, по роду своей работы, просто вынужден оперировать многими сущностями. И число этих сущностей часто превышает несколько десятков. Причем иногда взаимосвязи между этими сущностями оказываются очень хитрыми и черезногузадирищенскими. Потребности бизнеса и все такое.

Не верите? Смотрите, что произойдет в гипотетической (да, она идеальная) организации при приеме на работу нового сотрудника. Кадровик вбивает в какую-нибудь систему “принят на работу Иванов Иван Иванович”. Система отправляет данные в кадровую систему (заплата, паспорт и так далее), кадровая система переварив данные и проверив все, плюет запрос в систему поддержки (компьютер со столом надо? к сети подключить надо?), система поддержки раскидывает запросы к АХОшникам (за столами и стульями) и к айтишникам (логин, пароль, распределение по группам и прочие). Данные от айтишников убегают назад в кадровую систему (где сидит), на портал (где типа все тусуются, можно посмотреть телефоны и прочее) и дальше расходятся по другим бизнес системам (где-то надо завести каталог, где-то скрипт выполнить, где-то еще что-то надо делать). И все это попутно проверяется на ошибки, синхронизируется между собой и так далее. А потом приходит Иван Иванович и отправляет запрос “не хочу быть Ivan, хочу быть Vanya” и начинается легкий армагеддец внутри систем, которые начинают внутри менять данные, да так что бы не порвать уже налаженные связи.

И это очень простой процесс. Вон, я кратко в абзац уложился. В реальности кто забивает на такие закидоны, кто пытается автоматизировать этот процесс.

К чему это я? И вот представьте себе айтишника, которому поручили добавить еще одну подсистему в уже существующую связку.

Сначала он укладывает в голове то, что существует сейчас. Примите как данность, что одинаковых систем не бывает и у всех есть нюансы, иногда (хорошо, почти всегда) не описанные.
Потом он мысленно пробегает по взаимосвязям в духе “ага, это идет туда, а потом собирается вот тут и тут”. Говоря другими словами имитирует деятельность системы прямо в голове.
Следующим шагом он добавляет в полученную схему новое. Мысленно. “тут надо перехватить, сюда идут, отсюда выходят …”
И наконец, проиграв еще раз схему, он ее реализует в реальности.

Так или примерно так работает башка у любого айтишника. Разница обычно в глубине “охвата” и “проработки” деталей. Кто-то способен в башке удержать инфраструктуру целиком, а у кого-то мозгов хватает только на одну функцию.

И вот состояние, в котором пребывает айтишник во время подобного, кто-то называет “потоком”, кто-то “размышлизмами”, кто-то еще как. У авиадиспетчеров вроде это называется “поймать картинку”.

А теперь самое противное: это состояние довольно легко прерывается и надо начинать все сначала (реально сначала, функции save или pause не предусмотрено). Прерывается шумом за окном, разговором, звонками. И кому-то получается отключиться от раздражителей просто так, а кому-то необходима помощь. И именно поэтому, зайдя в разгар дня в любую айтишную компанию, вы увидите людей с наушниками. Айтишные комнаты и так обычно самые тихие в компании, а тут еще и наушники одевают. Все именно для сохранения “потокового” состояния.

Вернемся к матричному управлению. Про недостатки можете сами прочитать по ссылке, которую я дал выше. Позвольте обратить ваше внимание на только один недостаток: многоначалие.

Для примера возьмем обычного инженера по системе Х. Система хорошая, используется самой компанией, плюс продается и внедряется другим. И этот инженер в структуре матричного управления по проектам, связанным с этой системой. Проекты обычно в разной стадии: где-то пресеил идет, где-то уже поддержка, а где-то внедрение …

И вот садится этот инженер, берет задачу “включить хрень в Х”. Читает документацию, вникает, заходит на систему, начинает править … И тут прибегает продажник с “тут клиент звонит, Х умеет такую фигню через пипку?”. Бабах! “Потока” почти нет. Выяснили, чем пипка от фиговинки отличается, умеет ли Х это и так далее, “поток” ушел совсем. Начинаем снова. Через некоторое время прибегает менеджер с другого проекта с вопросом “ну как там внедрение Х?”. Бабах! Начинаем снова. И это в зависимости от “проектной” загрузки повторяется с завидной частотой.

Результат: “включить хрень в Х” проседает по срокам и качеству напрочь. Инженер, как любой нормальный человек, начинает нервничать и пытаться хоть как-то вытянуть задачу, а раздражители продолжают сыпаться … Все последующее можете додумать сами.

И именно поэтому я дал команду всех посылать. Да, это невежливо, зато “поток” не прерывается. А уже пришедшим ко мне с претензиями я пытался объяснить, что у нас есть специальный человек, который занимается распределением задач по инженерам и контролирует их. Вот с ним все вопросы и решайте. А лучше, что бы и его не расстраивать и дергать понапрасну, идите в почту/систему управления проектами и там уже описывайте свои хотелки. И долго неайтишные люди не могли понять, что же они делают не так … “ведь я только спросить, чего вам жалко что ли …”.

К сожалению, только ближе к концу все поняли, что от них требуется и схема заработала без нервотрепки всех сторон. Сколько нервов было безвозвратно уничтожено – подсчету не поддается …

Я начальник, а значит подчиненные должны быть зае…ными!

Жила-была компания. Хорошо жила, развивалась. Постепенно внутренняя инфраструктура обрастала серверами в ответ на растущие потребности компании. Почта, CRM, файлопомойка, багтрекер, проджект-сервер и так далее и тому подобное. И во всех этих системах начали накапливаться результаты по проектам. В почте переписка, на помойке файлики, в проджекте графики и ход выполнения … В общем, жизнь кипит.

Любой начальник знает, что подчиненных надо контролировать. А то будут делать не то и не туда. А еще ему надо отчитываться перед вышестоящим начальником, а тому еще выше. А как контролировать подчиненных? Правильно, совещания. А какая основная цель совещания? Понять, что сделано (или не сделано) за прошедшее время и что надо сделать дальше.

И вот начальник придумал гениальную мысль: а пусть все подчиненные присылают отчеты! А я буду их смотреть и сравнивать, что изменилось между прошлым отчетом и этим. Ну и буду ругать согласно не сделанному. Потом, ведь эти отчеты можно будет использовать и для докладов вышестоящему начальству! Кругом же польза для меня любимого. Легко задавив робкие “так вон же, все данные лежат …”, быстро смастерил табличку и грозным рыком разослал по подчиненным.

Поматерились подчиненные, но делать нечего. Ты начальник, а я дурак. Стали заполнять таблички. Кто про время, кто про задачи, кто про проекты. Понравилось это начальнику. Всегда есть цифры и прочие слова, которые можно предъявить кому угодно. И время на совещаниях меньше тратит.

Но потом внезапно понял начальник, что он начал тонуть в отчетах. А потом пару раз произошли факапы. И наказать не получилось: сотрудники предъявили старые отчеты, в которых они прямо предупреждали о этом. А ведь перед вышестоящим начальником отвечать ему, а не его сотрудникам.

Думал-думал начальник и решил заставить сотрудников писать сводный отчет. Дескать, все мы в одной компании работаем, вот и собирайте все в кучу. И снова будем совещаться и обсуждать. И началось раздолье: кто не успел, тот виноват, ату его! А сотрудники стали тратить половину дня в выяснении, у кого последняя версия файла, почему кто-то записал то, когда в реальности вон то … нет, они потом сообразили использовать Google Docs, но все равно: потери времени были чудовищными.

А ведь будь начальник потолковее, возглавил бы процесс объединения систем, благо знания про такие системы были у его подчиненных, настроить отчетность как надо и реально получил бы инструмент контроля …

… что я узнал на своем опыте и что невозможно прочитать в книжках. Часть первая.

Я обещал описать методы, ведущие к максимальному быстрому развалу компании. Но у меня не получается писать в отрицательном ключе, даже с улыбкой. Поэтому название оставлю прежнее, а формат оставлю наиболее привычный: “рассказка от первого лица”. Все описываемое было в реальности.

Как обычно, отмазка: все совпадения с реально существующими людьми и компаниями случайны. На самом деле: многие из знающих меня смогут соотнести описания с реальностью и попытаться персонализировать персонажей. Кто-то это сделает правильно, а кто-то нет. Систематизируя свои заметки, я обнаружил что некоторые события повторялись в разных компаниях практически один-в-один. Только при одних событиях я был юн и мне было пофиг на творящееся вокруг, а в развитии других событий я принимал самое активное участие. И не всегда положительное …

И хоть кто-то там из великих говорил, что только умные учатся на чужих ошибках а глупые на своих, но некоторые события осознаются только тогда, когда уже поздно махать руками. В общем, рассматривайте это как некий аналог “советов”, а не как наброс говна на вентилятор. Все равно все уже закончилось, а будущее я видеть не умею.

… гоните своих рекрутеров нафиг!

Стандартная ситуация: компания развивается, требуется все больше и больше людей и как обычно вчера. При этом ваша компания супер офигенная и ей реально нужны люди, а не “грузчики обыкновенные, ящики катать приученные, количеством 100 штук”

Как обычно решают такие задачи?

Самое плохое решение: свалить данную нагрузку на занимающегося кадровым делопроизводством или кадровика. Ну в самом деле, раз она считает отпуска, то уделить пару-тройку часов всяким сайтам вакансий сумеет. Матерящаяся про себя кадровичка кое-как собирает требования, находит первый попавшийся сайт в сети и вывешивает туда вакансию. Потому что не первые попавшиеся сайты обычно за размещение вакансий требуют денег.

Максимальный результат, который можно получить в этом случае – это случайно залетевшее резюме. Ничего нормального по такому поиску не придет.

Следующее по маразму решение: нанять собственного рекрутера. Человек, который все свое рабочее время будет посвящать процессу, связанному с поиском резюме, сравнению требуемых параметров и тупому пинанию начальников, для которых идет поиск. Тут результат будет пожирней, просто из-за того, что на процесс выделен человек.

И наконец, апофеоз: заплатить за поиск человека специализированному агентству. Размер пафосности – по усмотрению.

Почему это плохо? Ведь многие так работают и ничего …

Первая и самая главная ошибка состоит в том, что поиск и отсев людей ведут рекрутеры, которые абсолютно ничего не понимают в той области, в которой ищется человек. И если вы думаете, что “специализированные” агенства будут панацеей, то вы ошибаетесь: все их отличие в том, что девочки и мальчики там не боятся специализированного жаргона.

Вторая ошибка состоит в том, что “продвинутые” люди не умеют писать “правильные” резюме. Категорически. У них либо куцые резюме, на которые без слез не взглянешь, либо наоборот очень развесистые. Обыкновенный рекрутер такие резюме попросту пропускает. Продвинутый в лучшем случае даст посмотреть со словами “поглядите”.

И наконец, в случае агентств срабатывает еще один фактор: они попросту не показывают “спорных” кандидатов заказчику. Ибо “иначе они решат, что мы им подсовываем плохих”.

А как же собеседования? Собеседования штука хорошая, но посмотрим, как это обычно происходит.

Первое собеседование обычно делают по телефону. Ну типа вы “все еще ищете работу”, “а вы сталкивались с хрензнаетчем” и так далее. Так сказать, пристрелочное. Они ни к чему не обязывает, просто проверка голосом.

Второе делают обычно живьем. Расскажите подробней о работе, а почему вы оттуда ушли, кем вы видите себя в компании через 100 лет и прочий подобный бред. На данный момент я прошел подобных собеседований с десяток и могу утверждать, что задаваемые вопросы одни и теже. Видимо где-то есть книжка “юного рекрутера”, где все это описано. Хорошо еще, что мода на “закавыристые” вопросы как “в гугле” прошла. По крайней мере я только в одном месте услышал вопрос про круглые люки.

Следующие иногда совмещают, а иногда нет. Тут идет разговор с руководителем, куда идет прием. Именно тут иногда дают тестовые задания, расспрашивают подробно про знания и так далее и тому подобное.

В общем, от резюме до работы работника отделяет 4 фильтра (написать резюме это тоже фильтр). Вдумайтесь: четыре фильтра, три из которых отсеивают по чему угодно, но только не по профессиональным навыкам. Не знаю как вам, но лично мне это кажется неправильным.

Что получаем в результате? Получаем в результате практически случайную выборку и слова про то, что найти невозможно …

Что делать? Все просто: не стоит применять методику, рассчитанную на массовость для найма одиночных людей. Как это делал я, когда делал.

Во-первых, дайте понять, что вы ищите работника. На кадровых сайтах, на тематических форумах, в соцсетях и прочих местах, где вы тусуетесь. Кстати, кадровые сайты можно отдать на откуп рекрутеру, а форумы с соцсетями – персоналу. Главное дать им ниженаписанное.

Во-вторых, чуть-чуть (реально совсем чуть-чуть) формализуйте параметры. Типа ищем инженера, умеющего работать с системами резервного копирования. Обязательно укажите нижний и верхний уровень зарплаты. Никаких “по договоренности”. Ибо “по договоренности” всегда означает “ниже рынка”.

И самое важное: напишите небольшую задачку по теме. Раз мы ищем инженера по системам бэкапа, то задачка может быть в духе “у нас есть 100 серверов, на 80 из них 100 гигов мало меняющихся данных, а на остальных по 20 гигов быстро меняющихся данных. Примерно половина из этого объема – одно и тоже. Необходимо все это зарезервировать и обеспечить полное восстановление любого набора за час, а хранить данные год. Бюджет любой. Опишите архитектуру, ПО и прочее необходимое. Срок написания – три дня.”. Главное, что бы на описание решения надо было потратить максимум час (а лучше меньше).

И любому пришедшему просто давайте эту задачу. Несмотря на резюме, опыт работы и прочее. Поверьте, кандидаты оценят такую заботу. Во-первых, она позволяет им не тратить время и силы на бесполезные занятия. Во-вторых, это позволит реально оценить свои силы и дать возможность описать идеальную систему в их понимании, ведь бюджет-то не ограничен (тут должен быть смаил).

И вам, как ищущему, тоже одни приятности: во-первых, вас никто не будет дергать на просмотр левых людей. Мой опыт говорит, что примерно на 100 резюме примерно 80 не ответят или ответят позже положенного срока. Во-вторых, вы в спокойной обстановке, когда вам удобно, сможете оценить способности кандидата и красоту предложенного им решения. Поверьте, иногда попадаются очень оригинальные решения, которые можно применить совершенно в другой сфере.

Тут обычно задают вопрос в духе “вот он описал решение на микрософте, а у нас линукс?”. Если это так критично, укажите это в задаче. Но поверьте, все эти системы устроены одинаково и работают по одним и тем же принципам. И “переобучение” с одной системы на другую или с одной библиотеки на другую обойдется гораздо дешевле (и принесет в дальнейшем гораздо больше), чем “раскачка” человека, знающего именно требуемую систему, но хуже. В общем тут препятствием могут быть только религиозные вопросы. Кто-то не терпит микрософта, а кто-то линукса …

Чуть не забыл еще один вопрос: “а что, если он решение подсмотрел в интернете и выдал за свое?”. Чушь. Если возникнет такое предположение (ибо обычно в интернете обсасывают какую-либо одну сторону решения), то пара-тройка вопросов “по теме” легко показывает, кто есть кто.

И наконец, понравившихся людей можно приглашать на собеседование. Лично для меня уже пофиг на всякие профессиональные качества (они проверены раньше), лично я смотрю на человека только как на личность. Как он выглядит, как двигается … Грубо говоря нравится он мне или нет. Иногда на собеседование приглашал его будущих коллег. Тут очень важны именно личностные качества. Ведь именно мне и коллегам придется вместе работать. И даже если он крутой профи, но вот если все внутри говорило что “не сработаемся”, то я отказывал. Один раз я преступил через это правило и все окончилось судом.

А теперь посмотрите: от четырех фильтров осталось всего два. Причем один первый работает лучше и с гораздо меньшими трудозатратами для всех сторон, чем четыре предидущих.

Почему же я (да, переходим на личности) перестал так делать? Чего там оправдываться, банальная лень (ведь еще столько надо сделать, сроки горят) и “мне за это не платят”. То, что происходили срывы сроков и прочие факапы из-за “некому работать” как-то относил к чему угодно, не к себе.

… сотрудника у заказчика контролируй, но замещать не смей!

Начиналось все как в хорошом бизнес-романе: компании нашли друг-друга, руководители договорились между собой, заключили договор и начали работы …

Согласно хорошей традиции обе компании выделили из своих рядов по сотруднику, которые и стали вести все дела. Или говоря по-другому, стали “точками входа”.

Долго ли, коротко, но у одной из сторон случился факап. Совершенно не важно, что именно: не сделали, сорвали сроки или внезапно поменялись условия. Главное, что возникла напряженность и слухи о этой напряженности начали проникать “наверх”.

Вы не поверите, но сотрудник “провинившейся” фирмы не стал заметать “сор под ковер”, а в меру своих возможностей и обаяния рванулся улаживать дела с другой фирмой. Нормальный в общем сотрудник. И так как возможностей у него хватало и обаяние пришлось ко двору, он практически выровнял отношения. В общем, договорился он с противоположной стороной на небольшие уступки по срокам и деньгам.

Но! Как обычно случилось но! Начальник провинившейся стороны, до этого практически не обращая внимания на проект (идет и идет, вроде никаких провалов, а мелочи они везде есть), внезапно решил самостоятельно и на высоком уровне урегулировать возникшие трения. Стоит ли говорить о том, что он даже не поинтересовался текущим состоянием дел, ибо все бегом-бегом и мимоходом?

А после “начальственного урегулирования” оказалось что конечные условия были гораздо хуже тех, до которых договорились между собой сотрудники. Для обоих сторон! Более того, данные условия были преподнесены как спасение проекта благодаря большому опыту начальника.

Но это мелочь. Хуже всего то, что оба (ОБА!) начальника, не слушая рассказов, сделали “втык” своим сотрудникам за то, что они “мышей не ловят”. Стоит ли говорить, что в результате обе стороны максимально забили на проект (а нафиг пахать, если все равно вые..ут)? Итог: хороший проект похоронен, обе стороны понесли потери, сотрудники демотивированы.

А ведь стоило уделить буквально 15 минут и поинтересоваться у сотрудников текущим положением дел перед “урегулированием”, как все было бы не так …

Думаю, для первой части хватит, а то я расписался что-то 🙂

Вот уже прошло полгода (ну или пройдет), как я кручу баранку. Что имеем на данный момент?

Из него ничего не течет. Совсем.

Это я заехал на только-только выпавший снег и оставил на ночь. Будучи бывшим ведроводом, знаю поговорку про “если сухо, значит все уже вытекло” и регулярно сую нос в разные дырки и отверстия. Есть жидкости. И крышка омывайки всё никак не лопнет …

Расход горючего “по москве” устаканился в районе 15 литров на сотню. Я практичеки уже до рубля угадываю, сколько будет на счетчике колонки. Опять ничего нового.

Опять же, я залез с рулеткой под машину. На 245/75 просвет под передним редуктором составляет 21,5см. Я довольный. Но все равно посматриваю в сторону 235/85 …

И наконец, я собрал всю свою волю в кулак (а то лень-матушка …) и решил наконец-то избавиться от скрипа (это скрип? да руль вибрирует при повороте) в руле. Как полагается, предварительно прочитав в интернете все, что смог найти.

Для избавления от скрипа надо всего две вещи: среднюю крестовую отвертку с жалом подлиннее и напильник. Но для начала надо понять, что именно скрипит. Для этого откручиваем снизу 4 самореза из-под руля: два перед замком зажигания и два прикрыты резинкой за замком. Некоторые еще отцепляют накладку из кожи, но она у меня отвалилась с обоих сторон сама.

Смотрим на руль:

Видите “нашорканную” полоску? Это нашоркалось кромкой крышки

Некоторые (не будем показывать пальцами) просто смазывают либо руль, либо эту кромку какой-нибудь силиконовой смазкой и делают вид, что все в порядке. Во что превратится руль и как быстро оно снова заскрипит, набрав пыли, решайте сами.

Я решил просто подточить кромку. Напильника у меня нет, поэтому на его замену вышел Dremel.

Шикарная крутилка на аккумуляторе. При желании выдает 30 тыщ оборотов … Железяки режет только искры летят! Кхм. В общем, надел “наждачный” круг и просто снял с кромки пару миллиметров пластмассы.

Примеряю …

Даже при сильном нажатии остается зазор, не говоря уже о обычном состоянии. Стоит ли говорить, что скрип точно так же исчез? Мелочь, а приятно.

И наконец, сменил дворники. Решил побаловать нас (я и Дрынь) любимых и взял крутые, навороченные …

В общем, я теперь гламурен немерянно. И зона очистки у них чуть-чуть побольше родных. Опять же радостно. А тем, кто тыкал в меня пальцем, хихикая что я дворники чуть не разломал, вот вам картинка про способы крепления дворников. Считайте сами, сколько вариантов:

Говоря пафосными словами, у меня завершился очередной этап в моей карьере. По традиции принято подводить итоги, считать цыплят и совершать прочие подобные ритуальные действия.

Если коснуться технической области моих знаний, то никакого прорыва не свершилось. Простое линейное расширение объема знаний и способов их применения. Говоря другими словами, если раньше … ну скажем для “облаков” я знал как использовать только OpenVZ, то теперь я обладаю опытом использования Xen, KVM, VmWare и многих других страшных слов. И так практически во всех областях: от разработки до внедрения и поддержки.

А вот в области “менеджерских” знаний был прорыв. Мне первый раз за всю мою карьеру предоставилась возможность понаблюдать, как надо гробить компанию. С чувством, толком и расстановкой. В принципе, именно из-за этого я и сидел в “Пингвине” до конца. Про это никто и никогда не пишет в книжках для “успешных менеджеров”. Максимум легчайшими касаниями проходят мимоходом, попутно осуждая и говоря что так делать не надо.

А по-моему это наоборот самое главное. Этого просто так не дадут увидеть человеку со стороны. И никто не расскажет, что бы поучиться на чужом опыте (ведь помним, что умные учатся на чужих ошибках, а глупые – на своих?). Ведь со стороны компания должна быть успешной, процветающей и вообще, нельзя выносить сор из избы. А теперь компании больше нет. И все равно не ждите откровений – этого все равно никто не поймет без знания ситуации изнутри. Но вот пару рассказок “по мотивам” точно будет. Очень уж поучительные истории были, в стиле “вредных советов”.

В общем, спасибо всем за огромный вклад в мое образование. Это реально дорогого стоит.