Поиск по сайту

bit.samag.ru

Web

Рассылка Subscribe.ru

подписаться письмом

Вход в систему


Запомнить меня
Регистрация Забыли пароль?

О журнале

Ваше мнение

Статьи

Общие тенденции и тренды

Архив

Мероприятия

Календарь мероприятий

декабрь

2024

показать все

Новости партнеров

07.12.2024

Avanpost FAM/MFA+ стали еще безопаснее: вышла обновленная версия системы аутентификации

07.12.2024

M1Cloud: Итоги 2024 года на российском облачном рынке

06.12.2024

Действия сотрудников назвали главной причиной утечек информации

06.12.2024

САТЕЛ представляет систему записи разговоров СИЗАР

06.12.2024

Efros Defence Operations, релиз 2.11: умная киберзащита

показать все

Статьи

12.12.2024

Что следует учитывать ИТ-директорам, прежде чем претендовать на должность генерального директора?

11.12.2024

Сетевая инфраструктура, сетевые технологии: что лучше – самостоятельная поддержка или внешнее обслуживание?

22.11.2024

Тандем технологий – драйвер инноваций.

21.11.2024

ИИ: маршрут не построен, но уже проектируется

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

18.04.2024

5 способов повысить безопасность электронной подписи

18.04.2024

Как искусственный интеллект изменит экономику

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

показать все

Хроника одного проекта

Главная / Архив номеров / 2013 / Выпуск №2 (25) / Хроника одного проекта

Рубрика: Управление проектами

Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

Хроника одного проекта

Хотелось бы рассказать в форме дневниковых записей об одном проекте миграции центра данных, в котором мне довелось принимать непосредственное участие

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

Если вы узнаете кого-то из описанных мною действующих лиц у себя на работе, то все совпадения носят случайный характер.

Неделя первая

Сижу в кабинете у Джона – это мой начальник. Жду, когда он придет. Наконец-то принято решение о портировании нашего приложения для работы под Apache Tomcat – Linux OS. Сейчас все работает в связке Windows Internet Information Sever → Windows Tomcat → Windows ColdFusion.

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

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

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

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

Неделя вторая

Итак, начинаем заниматься базой данных. Майкл – сотрудник, отвечающий у нас в компании за базы данных, – должен связать два ЦОДа – один (старый) на Западном побережье, другой (новый) на Восточном, – чтобы данные были полностью синхронизированы. Если этого не сделать, придется или работать с неполным массивом данных, или делать довольно приличную паузу, пока все 400 Гб будут правильно перекопированы на другое побережье.

К счастью, у технологии MS SQL есть возможность создания полноценной копии – «реплики» данных в реальном времени. Она так и называется – «репликация данных» (см. рис. 1). Базы данных – это, как правило, самый значимый по ценности и по важности обслуживания элемент информационной структуры любой организации. Тот, кто не понимает, насколько тщательно надо планировать миграцию любой платформы базы данных, совершает грубейшую ошибку. Понятно, что даже простое описание работы с базой данных выходит далеко за рамки этой статьи, но ограничусь тем, что администратор баз данных – важнейшая фигура в отделе ИТ, и нередко он является правой рукой ИТ-директора.

Рисунок 1. Репликация данных MS SQL

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

А как все соединено? Вот где собака зарыта! (см. рис. 2) Мы для распределения нагрузки используем менеджеры нагрузки (Load balancers), устройства фирмы F5 Big IP, а у них все соединено напрямую. Это важная деталь, которую обязательно надо принимать во внимание. Адресация к серверам напрямую и через менеджеры нагрузки – это, как говорят в Одессе, две большие разницы.

Рисунок 2. Схема балансировки нагрузки

Менеджеры нагрузки высокого уровня от фирм Citrix (Netscaler), F5 (BigIP), CIsco могут делать много всякого интересного с входящим трафиком, но их конфигурация – управление пулами серверов, мониторингом (как определить, какой сервер подключен, а какой нет?) требует определенной квалификации. А при миграции центра данных или при тестировании продукта сторонними разработчиками это обстоятельство никогда нельзя упускать из виду. Мы на этом потеряли целый день.

Неделя третья

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

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

Если этого не делать, то можно быстро проиграть – на рынке информационных технологий выживает тот, у кого лучше поставлено дело.

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

Решение задачи:

полностью перевести все конфигурационные файлы в систему хранения версий;
полностью автоматизировать постановку учета версий («теги») и процесс сборки всех конфигурационных модулей;
в обязательном порядке использовать систему непрерывного развертывания типа puppet, chef, cfengine, построенную только на «тегах».

Неделя четвертая

Сроки, сроки, сроки... Сроки всегда поджимают. Но самое противное, когда сроки эти никто не понимает. На общем собрании разработчиков, куда были приглашены представители отдела проектирования продукта и маркетологи, случилось неприятное недоразумение. Главу отдела разработчиков долго спрашивали: «Когда все будет готово?» Не подозревая подвоха, он сказал: «К 1 июня». Эта дата была интерпретирована маркетингом как день запуска проекта. На самом деле с точки зрения разработчиков 1 июня – лишь срок окончания разработки нового Linux-кода, который нужно еще полностью протестировать по всем функциональным показателям и под нагрузкой. Дополнительно надо настроить все серверы, устранить зависимости («совсем забыли про Java us-export-файлы!») и только после этого ставить реальные сроки. Все эти тонкости, по понятным причинам, лежали за пределами понимания стратегов из отдела проектирования продукта и маркетинга – с их легкой руки дата «1 июня» пошла во все выпуски.

К счастью, отдел ИТ, который отвечал и за обслуживание маркетингового веб-сайта, вовремя увидел эту «опечатку» – пришлось проводить экстренное совещание с представителями «высшего командного состава», чтобы уладить ситуацию.

Неделя пятая

Находимся в неведении, что там нового в Linux-версии? Какие подводные камни? Какие именно компоненты нужны продукту для успешного запуска на совершенно «голом» сервере? Вот, например, мы только что случайно обнаружили зависимость от библиотеки clr [4], которую обязательно нужно установить на MS SQL-сервере. Хотя продукт в новом центре переписан полностью под Linux, он все равно опирается на базу MS SQL, ту же, что и в старом ЦОД. Ситуация стандартная и уже много раз описывалась как «яблоко раздора» между разработчиками и системными администраторами. Для достижения нужной функциональности продукта было решено использовать специальное расширение CLR User-Defined Functions, которое позволяет делать MS SQL-серверу много чего интересного. На тот момент разработчики еще не до конца понимали, сумеют ли они решить поставленные задачи, потому эта часть проекта делалась, что называется, «на коленке».

Кто-то пробовал использовать CLR, кто-то пытался найти какое-то альтернативное решение, но поднимать шум и проводить общее собрание отдела не стали. К огромному изумлению, функциональность CLR превзошла самые смелые ожидания, и окрыленные успехом разработчики сразу же передали все куски кода менеджеру проекта Мишель. Она же не имела ни малейшего понятия о том, что в отделе ИТ ни слухом ни духом не ведали об этой новой функциональности, которую, между прочим, надо установить и проверить на всех серверах! В итоге совершенно случайно выясняется, что ключевая компонента системы не установлена и не проверена. Параллельно приходим и к другому выводу: да, понятно, что так делать нельзя. Но попутно вскрылся факт, что разработка этого куска проходила по принципу «давайте кто-нибудь что-нибудь придумает и попробует, может, где-то и получится». Серьезная разработка и развертывание ПО должны всегда проходить по «заданному маршруту» – для решения задачи А есть технология Б, и для ее использования нужно установить В, Г и Д. Так поступают опытные разработчики и системные администраторы. А решение «методом тыка» никогда до добра не доводит.

Неделя шестая

Разбираемся с мониторингом. Мониторинг и служба сбора системных сообщений (логов) – это нервные узлы информационной системы, они просто обязаны функционировать четко и правильно. Часто системные администраторы чрезмерно увлекаются разными syslog, syslog-ng и генерируют массы логов, которые никто не читает, не понимает и не догадывается составить какие-то причинно-следственные закономерности.

Для того чтобы отыскать нужную «иголку в стоге сена», необходимы системы типа SEC [2], Splunk [3], и надо не полениться, чтобы их правильно настроить.

Чтобы системного администратора постоянно «теребили» всякими аномалиями от системы, которые неизбежно будут возникать, вполне подойдет старый добрый Nagios. Его тоже надо настроить на правильный уровень реагирования – в нормально работающей системе не должно быть никаких «мусорных» и «фальшивых» сообщений, а цвет приборной доски должен быть один – зеленый. Но слишком сильно увлекаться тезисом «на Западном фронте без перемен» или «нет новостей – уже хорошая новость» тоже опасно. Для чего тогда использовать мониторинг?!

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

Проверка удаленного «видеопотока»:

command_name check_streaming

command_line $USER1$/check_http -H flash.vx.roo.com -u /streamingVX/currentROO/83/83464_300.flv -s "FLV" -t 45

Проверка удаленной репликации – можно сделать через NRPE, здесь решение через check_ssh:

command_name check_mysqlreplication

command_line $USER1$/check_by_ssh -H $HOSTADDRESS$ -t 30 -l nagios -i /var/log/nagios/.ssh/id_dsa -C "/usr/lib/nagios/plugins/check_mysqlrep.sh -H localhost -u root -p password "

Проверка концентратора VPC3000:

command_name check_vpnc3000

command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C is_365_r -o IF-MIB::ifOperStatus.1,IF-MIB::ifOperStatus.2

Неделя седьмая

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

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

Проверяем и перепроверяем список требований – чем ближе к сроку сдачи проекта, тем важнее становится роль отдела тестирования.

Джон собирает руководителей отделов и вновь повторяет задачи, стоящие перед отделом тестирования:

Нужно еще раз проверить все планы по тестированию. «Планы по тестированию» – это как рентген-машина, которая дает «срезы» производительности и функциональной работы продукта. Что-то типа общего медицинского осмотра перед полетом в космос. В нашем случае это около 70 тестов, успешное прохождение которых дает «зеленый свет» на выпуск продукта.
Есть много ручных тестов – их обязательно надо автоматизировать через Jmeter, Jenkins, Badboy.
Надо провести встречу с отделом клиентских отношений: а насколько соответствуют эти 70 тестов современным требованиям заказчика? Может, мы упускаем какие-то важные части в функциональности, которые клиенты заметят, а мы нет? Вот этого допустить никак нельзя!
Тестирование по безопасности. Тема, которая часто игнорируется, но все имеющие выход в онлайн системы («а разве есть иные?») обязательно должны проходить и это тестирование.
Тестирование интеграции с другими системами. Все больше ИТ-продуктов обязано проходить функциональное и совместимое тестирование с Salesforce, Google apps. И мы здесь не исключение. Кстати, подобные тестирования по безопасности дают еще один повод проверить, есть ли дыры в безопасности.

Неделя восьмая

У каждого директора ИТ был в прошлом (а может, и в настоящем) такой крутой системный администратор, который мог сделать любой проект, исполнить любое поручение, бегло разбирался в широчайшем диапазоне технологий – от BGP-протоколов до триггеров в MS SQL, от знания заголовков HTTP до команд ассемблера.

У него был только недостаток – неспособность внятно рассказать или описать, как и почему сделано то или иное решение.

Расскажу и я о таком деятеле. Назовем его Брент. Он типичный линуксоид: черная футболка с надписью «Got root?», четырехдневная небритость, потертые джинсы, кеды и банка кока-колы в руке. Примерно так их рисуют на страницах комиксов про Linux, именно так они и выглядят в жизни.

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

Без Брента не обходится ни один релиз программного продукта. Без Брента невозможно установить новый сервер, так как он всегда скажет, что надо поменять в текущей конфигурации. Ну а если нужно поменять DNS- адресацию внутри DMZ-зоны, туда вообще без Брента лучше не соваться. По совершенно непонятной причине было потеряно соединение между маршрутизаторами – другие системные администраторы битый час пытались найти, почему же не проходит ping.

Наконец кто-то не выдержал: «Позовите Брента». Тот приходит, минут десять смотрит, потом что-то быстро печатает в терминальном окне, и – р-раз – заветные ping заработали. На вопрос, как ты это сделал, Брент просто смотрит перед собой: «Вот… сделал». Без единой нотки ехидства и злорадства. Просто человек так работает … Брент улетает на концерт Pearl Jam в Амстердам – все встало на две недели.

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

Неделя девятая

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

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

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

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

Процесс задерживается на полчаса – думаю, в 19.30 мы сможем все же открыть трафик. Параллельно выясняем, что за опечатка.

Ну, конечно же, тестовая инициализация происходила на 5+ с именами test1, test2, test3, а в «боевом режиме» у нас имена клиентов несколько другие: bankofamerica, wellsfargobank, citicorp, fidelity, morganstanley, вот где-то и вкралась досадная опечатка в названии. Спрашиваю: «А почему нельзя использовать те же самые имена и в тестовом режиме?!» В ответ: «Ну это же наши «реальные» базы, а не тестовые». Но что мешает создать «клон» всех «реальных» баз в тестовом режиме, предварительно удалив из самих баз информацию? Все же лучше, чем test1, test2, test3!!! По крайней мере проблем с опечатками не будет.

Успеваем все сделать к 19.30 – открываем трафик наружу. Все вроде работает. 5 минут, 10 минут, на 15-й минуте сообщение от Хьюго – у одного важного клиента нет данных в новой структуре. Через три минуты аналогичное сообщение от другого клиента.

Проходит еще 15 минут – мы понимаем: была упущена какая-то важная часть в процессе миграции. Но что делать?

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

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

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

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

Итог

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

Первое. Потеря доступа к сайту и потеря данных – самое плохое, что может быть для фирмы. Никого не интересует, какие технологии и нововведения были сделаны. «Ничто не сохнет так долго, как подмоченная репутация» – лозунг СССР 1985 года актуален и в мире ИТ 2013-го!

Все изменения в данных, запуск нового кода, новая структура должны иметь как можно меньший простой. Максимально, что можно сделать, – два-три часа выхода в «офлайн».

Второе. На всех этапах процесса надо иметь возможность «откатиться назад».

Третье. Многие системы должны поддерживать как старый, так и новые центры данных. Это нетривиальная задача, но ее надо решить.

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

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