Быстро и безболезненно. Как правильно запустить новый продукт

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

Быстро и безболезненно
Как правильно запустить новый продукт

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

Вот ситуация!

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

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

Это придется делать во внерабочее время, а предыдущий системный администратор, который не смог «поднять» неработающую систему после неудачной перезагрузки сервера, был с позором уволен. Никто, кроме него, не знает, как правильно и в какой последовательности все делать. Знакомая ситуация?

Я не случайно привел фрагмент введения книжки Continous Delivery («Теория постоянного релиза программного кода» – если по контексту) [1], а для того, чтобы показать, что с проблемой сложности и болезненности запуска новой версии программного продукта приходится сталкиваться в той или иной мере практически всем системным администраторам.

Кто такие DevOps?

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

• Программисты – ну, тут все понятно, их вотчина – программный продукт, разработка новых систем.
• Отдел технической помощи – «хелп-деск» – все, что касается пользователей и работы в офисе.
• Системные администраторы – серверная группа – все, что работает в серверной комнате, в центрах хранения данных.

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

Системные администраторы: «Продукт не работает, потому что он криво написан программистами. Сервер идеально работает сам по себе».

Программисты: «Продукт не работает, потому что системные администраторы используют некачественное «железо», которое они плохо сконфигурировали. Все идеально работает на МОЕМ компьютере».

Почему так? Системные администраторы не имеют ни малейшего понятия о системной архитектуре продукта, о том, что необходимо для правильного запуска и функционирования системы, а программисты изолированы от реальных «боевых» серверов. Иногда попадались просто случаи из серии «нарочно не придумаешь». Разработка ведется на Microsoft IIS, а продукт «планируется» использовать на веб-сервере Apache.

Понятно, что такие ссоры и упреки до добра не доводят. Чтобы как-то разрубить этот гордиев узел, было решено попробовать объединить разработчиков (Developers) и системных администраторов (Operaitons) в такую смешанную группу с рабочим названием DevOps [4].

Ее цель и основные задачи – интеграция знаний, навыков, методов работы разработчиков и системных администраторов.

Разделяем код и конфигурацию

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

Большинство современных стандартов безопасности Sarbanes – Oxley, PCI [2], SAS 70 и другие сходятся в «концепции разделения прав доступа» – не должно быть технических сотрудников или групп, которые имеют неограниченный доступ ко всем информационным ресурсам фирмы.

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

Применительно к ИТ – подавляющее большинство фирм пошли по пути, когда программисты и разработчики не имеют прямого доступа к «боевым» серверам, а у системных администраторов нет доступа и прав редактирования исходного кода.

Замечание: если кто-то увидел противоречие «разделению прав доступа» идее DevOps, поясняю: DevOps знает, как и что работает со стороны продукта и инфраструктуры, но не обязательно имеет доступ в оба места одновременно.

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

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

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

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

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

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

Например:

• 192.168.1.0/24 – сеть разработки;
• 172.16.24.0/12 – сеть отладки и предварительного тестирования;
• 10.0.8.0/8 – «боевые» серверы.

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

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

Таблица 1. Пример списка подсетей в сложных системах

Исходя из этого разработчики продукта не видят, какая существует конфигурация у продукта.

Например, фирма имеет дело с клиентами «Клиент1», «Клиент2», «Клиент3», у каждого из которых есть выделенная база данных, где находятся реальные данные. Для разработки, начального тестирования и отладки можно использовать парочку тестовых баз «тест1», «тест2». Но как приложение сможет работать с «боевыми» базами? А что делать, если число клиентов перевалило за несколько сотен?

Разработчики просто физически не смогут удержать все данные о клиентах и будут постоянно отвлекаться отделом продаж: «С 1 мая удаляем клиентов №16, 26 и добавляем 77, 78 и 79».

Получается, придется давать доступ к реальной информации разработчикам, что запрещено политикой разделения доступа. Что же делать?

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

Все, что касается доступа к конкретному серверу или базе, переходит в компетенцию системных администраторов. Конфигурационная база (Configuation Management – CMDB) может содержать простую информацию – адреса серверов для тестового или «настоящего» релиза, а может, и более сложную – имена и доступ (DSN, ODBC) на все базы, пароли в хкэш-форме, ssh-ключи и т.п.

Общая топология CMDB представлена на рис 1.

Рисунок 1. Топология базы конфигурации продукта

Пример простой конфигурации через Cfengine:

test::
            ganglia_cron = ( "crontab_ganglia" )
 production::
                        ganglia_cron = ( "crontab_ganglia__port_80" )

###########################################################
copy:
            any::
                        $(master_etc)/cron.d/$(ganglia_cron)
                        dest=/etc/cron.d/crontab_ganglia_apache
                                    mode=644
                                    type=checksum
                                    server=$(cfengine)
                                    encrypt=true
            owner=root
            group=root

До этого кода мы подразумеваем, что система как-то определила, на каком «test» или «production» исполняется данный кусок кода, затем просто объявляется переменная ganglia_cron, которая в зависимости от типа сервера копирует нужный нам конфигурационный файл в /etc/cron.d/crontab_gangalia_apache.

Cfengine в этой связи достаточно эффективный инструмент для хранения и использования различных конфигураций, которые, кстати, могут меняться. По поводу Cfengine мы уже рассказывали в [3].

Кстати, Cfengine можно идеально использовать для управления релизами (см. рис. 2).

Рисунок 2. Cfengine можно идеально использовать для управления релизами

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

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

Многие годы ПО, написанные под ОС Windows, имели свойство думать, что ОС Windows может находиться только в каталоге C:\WINDOWS, а установку надо проводить только на диск C: – эти конфигурационные переменные были просто «зашиты» в систему, и программа отказывалась правильно устанавливаться в любое другое место. К счастью, этот «баг» сегодня практически невозможно встретить.

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

• конфигурации файлов инициализации для работы – отвечает отдел ИТ – с точки зрения ИТ, эти базы должны быть доступны для приложения
  • база тестирования – test.db.
  • база предварительного запуска – staging.db.
  • основная рабочая база – production.db.
• основная рабочая база – production.db – занимается отдел продаж. Задача этого отдела – «наполнять» базу клиентами. О том, что это за клиенты – кто новый, а кто больше не используется, – ни отдел ИТ, ни тем более программисты не имеют ни малейшего понятия.
  • Клиент 1.
  • Клиент 2.
  • Клиент 15.
  • Клиент 24.
  • Клиент 77.
  • Клиент 78.
  • Клиент 124.

Тестировщики: зачем они нужны?

Тестировщики (QA – Quality Assurance), известные также как «тестеры», – это чрезвычайно важный элемент штатного расписания, а отдел тестирования (QA) должен работать как структура, параллельная отделу разработки продукта и отделу системных администраторов (см. рис. 3).

Рисунок 3. Структура отделов

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

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

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

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

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

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

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

Если этого не сделать, то можно случайно поломать что?то еще.

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

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

После того, как разработчики закончили отладку нового продукта (или программного модуля) и подготовили его для тестирования, включаются в работу те самые тестировщики.

Работа QA – это не просто проверка, что веб-сайт работает, а «окошко» открывается. Надо полностью проверить функциональность продукта – от и до, составить план тестирования, залезть в самые труднодоступные места проверяемой системы, а также попробовать смоделировать все мыслимые и немыслимые варианты работы.

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

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

Рисунок 4. Для адекватного тестирования программного продукта необходимо подготовить несколько серверов, на которых бы был размещен программной продукт в разной степени готовности

В самом верху – Release – находится именно та версия, которая идентична (до последнего байта) той, что находится на «боевых» серверах. Это полная копия того, что сейчас работает, – она нужна для оперативного анализа тех или иных свежевскрытых ошибок: если клиент обнаружил какой-то «баг» на «боевом» сервере, он немедленно проверяется.

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

• Dev – это стадия разработки, самая свежая, то есть сырая версия продукта, над которой идет работа.
• Minor, Sprint, Patch – разные «ветки» разработки. Их может быть то или иное количество в зависимости от применяемой методологии разработки и типа продукта.

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

Отдельно пару слов надо сказать и о «тестировании под нагрузкой».

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

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

Этапы запуска продукта

«Релиз кода» и «Запуск продукта» – две большие разницы, которые надо воспринимать в разном контексте.

Новый код, выложенный на серверы и доступный для скачивания или для он-лайн доступа, вовсе не означает выпуск нового продукта.

Кроме собственно нового «программного кода», следующие шаги должны быть предприняты организацией для «запуска продукта»:

• Маркетинговая программа и промоутинг. Сюда входят сообщения на сайте, пресс-релизы, реклама и т.п.
• Предпродажная подготовка. Организация должна четко представлять, кому и за сколько будет продавать продукт. Кто является клиентом и потенциальным покупателем. Является ли продукт новой платформой для разработки, прорывом или лишь «бесполезной игрушкой». Каков сегмент и потолок рынка?
• Подготовка отдела поддержки. У каждого программного продукта есть пользователи – кто будет заниматься их обучением, процессом перевода на новую версию, поддержкой и ответами на вопросы?
• Готовность отдела разработки «видеть за горизонт» – является ли текущий «релиз» промежуточным, первой моделью нового продукта или финальной версией продукта, который прекращен? Когда планируются новые выпуски? Какие архитектурные и структурные изменения потребовались в текущей и потребуются в новых версиях? Если, например, выпущена система, в основе базы данных которой лежит продукт Microsoft SQL Server 2005, то резонно спросить, а почему в 2012 году сделано именно так? Планирует ли архитектор информационной системы и дальше использовать технологии Microsoft при разработке? Если да, то когда будет переход на SQL Server 2008? 2012? Если нет, то какая новая база будет использована и в какой стадии находится подготовка плана по миграции на новую базу? Какую? Oracle, IBM DB2, Postgress, MySQL, NoSQL и т.д.?

Все это является составными частями стратегического плана запуска продукта.

***

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

По каждому разделу можно написать отдельную статью, что попробуем сделать в ближайших номерах «Системного администратора».

1. Jez Humble, David Farley. Continuous Delivery. – Addison-Wesley, 2011.
2. Кондаков К. PCI – стандарт надежности ИБ при работе с кредитными картами. //«Системный администратор», №10, 2011 г. – С. 106-112 (http://samag.ru/archive/article/1454).
3. Кондаков К. Cfengine: как применять? //«Системный администратор», №7-8, 2010 г. – С. 69-75.
4. DevOps – http://www.jedi.be/blog/2010/02/12/what-is-this-dev.

Комментарии могут оставлять только зарегистрированные пользователи