Возможно ли использование практик и подходов DevOps, CD в корпоративной среде?

Какие особенности?

SPARC + Unix (Solaris)

Вертикальное масштабирование и как следствие — разная конфигурация в бою и на стейдже.

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

Финансовые сервисы 24*7, невозможно останавливать приложение днем даже на 5 минут. Плановые работы только с 1 до 2 ночи.

Много бизнес-логики в СУБД (Oracle). Невозможно обновлять систему без останова даже в условиях кластеризации.

Как итог — нет возможности ставиться по несколько раз в день или хотя бы каждый день.

Среда до уровня middleware включительно готовится для развертывания нового инстанса вручную системными администраторами.

Дистрибутив передается через файловую шару.

Инструкция по установке — огромная портянка в Confluence с множественными noformat вставками. Точечная автоматизация на Bash-е.



Путь самопознания через боль

Про девопс не знаем ничего, гордо живем в ультраспецифичной "особенной" среде финансовых сервисов. Подходы 80-х. Давайте меняться. Зачем? 30 лет работало, значит хороший подход!!!
Вы, главное, поменьше версий ставьте, а то у вас каждую неделю проект запускается — бардак!!! Но как же так? Бизнес же должен развиваться? Развиваться нужно вдумчиво!!! Качество, скорость и стоимость — выберите два из них и...
Да к черту. Пока вы выбираете 2 из 3 придут стартаперы, которые на новых подходах сделают 3 из 3 и мы останемся у разбитого корыта.


Начали меняться. Манифест о разграничении ответственности и сопровождения и админов. Админы думают, а не исполняют команды, которые мы за них напишем. Интенсивность версий и частота запуска проектов — данность, будет только больше. Это дождь. Не спорь — адаптируйся.
Как итог — 2-е из 4-х админов уходят в другие сервисы, где можно жить по-старому. Ну и что, мы идем дальше. Балласт не нужен.

Этого мало. Простои из за кривых настроек на боевой, проблемы с развертыванием новых модулей, затяжные ночные работы с побудкой всех по ружью. Что делать? Ок, ITIL.
Внедряем Релиз менеджмент и управление изменениями.

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

После изменений на боевой — о чудо!!! убеждаемся, что в результате получилось то, что хотели.

Параллельно работа с разработчиками. Фича готова только тогда, когда на боевой пошли транзакции, и они обрабатываются правильно. Для разработки убираем Shit Umbrella.
Отныне — коллективное владение всем дерьмом, что летит от клиентов!



Когда убрались в комнате, стало ясно что все обветшало
Управление релизами и конфигурациями позволило практически исключить простои из-за некорректных изменений, и сделало прозрачным вынос обновлений. Однако прозрачность не добавила успешности. Много детских ошибок:
1. Огромное количество одинаковых ручных операций на эталонном и затем боевом комплексах. Ошибки человеческого фактора.
2. Дистрибутив через шару — периодически выкладываем не то, ставим не туда.
3. Прикладная логика ведет себя на боевой не так, как на разработке в силу различия конфигурации.
4. Архитектурные решения, принимаемые разработчиками в отрыве от саппорта и админов, при выносе на реальную конфигурацию оказываются не приемлемыми. Обсуждение на предустановочной встрече — слишком поздно.

Что же делать? Помню в 2012 году разработчик приехал с конференции HighLoad++ и рассказывал про доклад некоего Титова по управление конфигурацией. Приставал тогда ко мне этот разработчик с каким-то Chef-ом. Какой-то админский бутор со скриптами для автоматизации конфигурации. Не, это не то, я же тогда CMDB внедрял. Мне надо контролировать конфигурацию, а башскрипты админы и сами могут написать.

Хм... ну внедрил ты CMDB — легче стало? Нет :( Так может все-таки посмотрим, что это за чиф такой.
Читаю, выхожу на ДевОпс, читаю про девопс бессонными ночами, читаю Феникса, статьи, смотрю доклады — и понимаю — так ведь решают наши проблемы? Это же ведь то, что надо.

К сожалению, не все так просто. Разграничение зон ответственности, полная изоляция ИТ о Дева, ну и наконец Unix!

Но мы можем с чего-то начать! Давайте двигаться.

Что сделали:
1. Регулярная синхронизация производственного стейджа с боевой схемой развертывания.
2. Включение прикладного сопровождения в продуктовые команды, участие в выработке правильных архитектурынх решений.
3. Процесс управления доступностью, анализ всех проектов с точки зрения паттернов высокой доступности.
4. Переход на IPS для передачи дистрибутивов.
5. Организация полного конвейера для джава приложений с производственных комплексов на бой при помощи чиифа. В процессе — выкатка веб-приложений. Пока только выкатка...
6. Одно приложение целиком выносим паппетом, для разнообразия.
7. Есть еще виндовс приложения. Пробовали и используем РМ, но это какой то отстой...
8. Веб-приложения катим в онлайне, кластеризация на апаче.
9. Патчи на Оракл катим в онлайне, благодаря технологии EBR.
10. Тестирование и отладка рецептов на нодах vagrant.
11. Команда ДевОпс... тут поговорим отдельно.


Когда удалось донести и до разрабов и до админов пользу от CD и ДевОпс, руководители отделов начали выстраивание двух конвейеров. И если это начиналось с прицелом на их смычку в итоге, то руководитель администраторов постепенно все больше и больше фрустрировал от новой роли своего отдела, от размытия изоляции, от вливания в команду.
В итоге дошло до того, что он физически спрятал в недра своего redmine-а всю свою документацию по проекту. И по сути мы получили двух уродов братьев близнецов DevDevOps & OpsDevOps

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

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

Планы до конца года:
1. Выкатка всего, кроме СУБД, рецептами.
2. Начать изменения конфигурации также рецептами.
3. Виндовс приложения на паппет.
4. Oracle Linux пробовать.
5. MCollective.
6. Получить рута и готовить окружение также рецептами.

Чего мы не сможем получить никогда:
1. Обновления каждый день. Максимум — 2 раза в неделю
2. Docker — да, увы, Юникс.
3. Горизонтальное масштабирование и стотыщь нод — не наш путь.
4. Версия Х с чистого листа на любой ноде. Логика в БД еще очень надолго...