Представьте себе фантастическую ситуацию — директор компании решает внедрить DevOps. Сам, без давления со стороны технарей. Без убедительного примера конкурентов. Руководство само признало, что повысить качество продукта, предсказуемость, прозрачность и повторимость бизнес-процессов при разработке и внедрении ПО невозможно без средств DevOps.
Представили? Получилось? Вы успешно прошли тест на самое богатое воображение!
На самом деле, конечно же, всё не так. Чаще всего руководству не до наших ИТ-шных штучек. Поэтому приходится убеждать. Но как?
Когда в качестве аргумента приводится повышение культуры общения между программистами и системными администраторами, то легко можно нарваться на контраргумент: а сейчас вы некультурные, что ли? Или даже могут напомнить о затратах, которые уже понесла компания год-два назад, когда вы дружно переходили на Agile. Неужели в ИТ каждый год появляется фича, способная продвинуть процессы революционным способом?
Насчёт повышения качества продукта тоже можно заикнуться. Но осторожно. Поскольку задачу программировать без ошибок ещё никто не отменял. Да, без багов никак, но именно поэтому в компании есть «целый отдел тестировщиков», не так ли?
Предсказуемость процессов — это вообще такой субъективный фактор, обосновать который и избежать шуток про Вангу и Нострадамуса довольно сложно.
При этом, если мы говорим о типичном энтерпрайзе, то в такой компании, скорее всего, есть уже сложившаяся ИТ-команда. И эта команда в старом (если не считать Agile) привычном ритме трудится вместе немало лет и вряд ли горит желанием (опять) что-то менять. Всех всё устраивает, кроме, естественно, руководства. Которое видит, что в их ПО постоянно сыплются какие-то ошибки, смещаются сроки выпуска новых версий.
Конечно, можно предположить ещё один вариант, когда в компанию приходит человек с опытом в DevOps, ясно представляющий, в чём проблема и как её нужно решать. И который способен донести своё мнение до руководства. Однако давайте не будем надеяться на чудо-дядю.
И на этом многие ломаются. Начинают говорить, что никто их не поддерживает, что в этом болотце ничего внедрить невозможно и затем просто уходят в другую компанию, где цикл повторяется.
Получается замкнутый круг? Нет, просто постепенно мы приходим к выводу, что с бизнесом нужно говорить только на понятном ему языке — на языке денег. Для этого мы достаём из широких штанин рукава главный козырь — сокращение Time-to-Market. Нужно показать, что благодаря DevOps новые версии продукта будут выпускаться, как горячие пирожки. А все остальные вышеперечисленные выгоды от внедрения DevOps давайте оставим для итоговой презентации, которую мы создадим для директора, когда все получится. Многие скажут, что это слишком очевидно. Нет!
Нам нужно что-то, что займет у нас минимум времени и ресурсов (ведь никто не разрешит списывать человеко-месяцы на внедрение некоего DevOps и не закупят для нас срочно новых серверов), но при этом даст очень ощутимый результат (реально сократит Time-to-Market).
Для начала нужно найти бутылочное горлышко, а оно всегда одно (первый шаг в теории ограничений Голдратта). После успешного внедрения Agile (а все это имеет смысл только после внедрения Agile), в плане разработки софта всё равно им остается ручное тестирование. Даже при наличии пула свободных рук, регрессионное тестирование может занять две-три недели. А уж от том, как тестировщики «любят» проводить регрессионное тестирование, знаю все.
Итак, мы определили, что бутылочным горлышком является тестирование. Тогда начать нужно с его автоматизации. Многие заметят: легче сказать, чем сделать. Уже написаны миллионы строк кода, и хорошо, если программисты хоть что-то покрыли модульными тестами. На самом деле все не так страшно, как кажется. Как показывает опыт, 80 % успешного результата в виде серьезного снижения Time-to-Market достигается за счёт 20 % усилий. Именно во столько примерно обходится автоматизация тестирования в нашем случае.
Совсем по закону Парето, ага.
И самое главное, запустить автоматизацию тестирования можно ещё до того, как руководство согласится выделить ресурсы на внедрение остальных частей DevOps. Небольшой такой пилотный проект, который можно сделать собственными силами за одну-две недели.
Но при этом такая ситуация нам даёт шанс одержать эффектную и, самое главное, быструю победу. После которой, имея позитивный настрой и благословение руководства, уже можно просить и деньги, и ресурсы.
Начнём с того, что, наверняка, ваши программисты уже используют какое-либо серверное ПО для ежедневной сборки. Это может быть TeamCity, либо Bamboo, либо Jenkins, — не принципиально. Главное, часть автоматизации уже есть и это нужно использовать, а если нет, то за день его легко развернуть.
Сначала надо автоматизировать «дымовые» тесты. А как понять, что автоматизировать? Да просто посмотрите, что у вас регулярно ломалось при выкладке изменений за последние полгода.
Дальше нужно создать несколько тестов проверки работы основных бизнес-процессов. Как их определить? Задать вопрос вашим аналитикам/директорам/представителям бизнеса, при какой поломке в кабинет к программистам вбегает разъяренный директор и ставит задачи повышенным голосом.
Неделя, ну максимум две на создание таких тестов. В результате — очень быстрый фидбек на предмет глобальных ошибок.
И пока проект в режиме proof of concept, не надо заниматься подготовкой того же автоматического развертывания сервера для тестирования и прочими бантиками, а всё сделать вручную. Эту красоту потом можно с удовольствием сделать вместе с админами.
К чему это приведёт, догадаться не сложно. Разработчики сразу будут видеть (и исправлять) свои ошибки. Тестировщики будут избавлены от рутины в виде проведения долгих и нудных тестов на регресс. Им останется пара-тройка дней для того, чтобы протестировать только те места кода, которые были подвержены правке. Да-да, именно так. А если нет, то вернитесь в начало и еще раз поговорите с аналитиками/директорами/представителями бизнеса на тему критичных для бизнеса процессов.
Бутылочное горлышко, из-за которого возникали основные тормоза, ликвидировано. Теперь остаётся только выпустить несколько новых релизов в продуктивную среду, снять статистику «было/стало» и идти с этими цифрами к руководству. Профит!
После такой убедительной победы уже можно разговаривать про автоматизацию развертывания стендов (как минимум для тестирования). Далее выпрашивать средства на мониторинг и прочие прелести DevOps. При этом нужно помнить, что остальные компоненты системы уже не будут иметь вау-эффекта для бизнеса.
Пример в студию
В завершение поста, думаю, уместно будет привести пример успешно завершенного проекта по внедрению DevOps, который реализовала наша компания.
У одного крупного ритейлера около 20 % бизнеса приходится на интернет-магазин. При этом реагировать на рыночную ситуацию и вносить необходимые изменения в ПО нужно очень быстро. И часто. И качественно. Любой косяк на сайте может повлиять на конверсию, риски выражаются в реальных деньгах.
Для сокращения времени обновления и повышения качества была создана специализированная платформа автотестов, на которой были автоматизированы рутинные задачи по тестированию изменений и регресса сайта. Кроме того, был выстроен процесс взаимодействия группы автоматизированного тестирования с командами разработки. Это позволило разработчикам сразу выявлять и исправлять дефекты в обновляемой системе, не дожидаясь финального приемочного тестирования.
Представители ритейлера сочли опыт успешным и решили применить его к остальным софтверным продуктам.
И ещё небольшой пример, но уже из практики одной крупной страховой компании. До внедрения автоматизации тестирования релизы выходили раз в полгода. Не потому, что так требовал бизнес, — просто чаще не получалось. А заказчик как раз хотел. Так вот, через два месяца после начала внедрения средств автотестирования, ИТ-команда перешла на двухнедельные итерации выпуска релизов.
Достаточно показательно, чтобы начать этим заниматься, не так ли?
Сергей Страмнов, пресейл-архитектор Центра программных решений «Инфосистемы Джет»