Команды разработки могут быть слабо связаны между собой и работать в разных направлениях, не зная и не желая использовать DevOps. В сегодняшней статье мы расскажем о том, насколько практики DevOps могут искажаться и трансформироваться, чтобы их можно было реализовать в компании с давно устоявшимися регламентами, политиками и привычками людей.
В основе материала — доклад-диалог Сергея Бердникова (Золотая Корона) и Артема Каличкина (ЦФТ) c октябрьской конференции DevOops 2017. Под катом — видео и текстовая расшифровка доклада.
Сергей: Я руководитель отдела эксплуатации в нашей компании. Мы с Артемом затеяли небольшую революцию-эволюцию. Всё начиналось с революции, сейчас перешло в стадию эволюции.
Артем: Компания работает на финансовом рынке с 1992 года. Работа состоит из двух основных частей. Первая часть — это разработка программного обеспечения, Core Banking, банковская бухгалтерия и так далее. Здесь мы выступаем в качестве вендора: мы разработали и продали вам коробку, а вы ее развернули и эксплуатируете.
Вторая часть — процессинговые сервисы. Здесь мы предоставляем услуги либо напрямую физлицам, либо через наших партнеров. Это крупные торговые сети, банки, другие участники рынка финансовых услуг. Тут мы отрабатываем полный цикл от идеи до разработки, реализации и дальнейшей эксплуатации.
Мы с Сергеем работаем в процессинговой части нашей компании. Про то, как мы приходили к истории с DevOps в этом процессинге, мы и расскажем.
Что было
Сергей: Наследие у нас было полностью банковское. Компания изначально делала банковские продукты, соответственно, всё было привычное: вся инфраструктура SPARC only, собственные ЦОДы, всё ядро написано в Oracle. PL/SQL-код, много всяких штучек — это нелегко масштабировать.
Мы масштабировались только вертикально: покупали мощную железку, пользовались ей, пока не устареет, заменяли на новую и старую уводили в staging.
Также писали много кода на Java. Мы резервировались через теплый резерв: есть ЦОД, и полностью вся скопированная структура — свичи, сервера, все один в один, болтик к болтику.
Тут можно увидеть, как выглядела вся структура с точки зрения процессов. Были отдельные технические дирекции Dev, дальше Firewalls с огнем. Дальше было централизованное IT, которое занималось выносом, деплоем и так далее. То есть Dev-ы писали большую инструкцию, а IT Operations делилось на три подразделения:
- Прикладные администраторы, которые занимались деплоем. У них не было рута, на машинах были пользователи, они могли исполнять инструкции — это называется Monkey code.
- Unix-администраторы, которые могли и умели конфигурировать, наливать железо и так далее.
- Были отдельные специалисты по базам данных. А так как базы данных для нас — это основная цель, суть нашего существования долгое время, там происходило множество процессов.
Артем: DevOps здесь никакого на этом этапе еще нет, мы работали по регламентам, чем Сергей не был доволен.
Сергей: Я пришел в команду прикладных администраторов и помню, какие это были «прекрасные времена». Мы могли делать одну заявку три недели. Приходит заявка, в ней находили какую-то ошибку и отменяли, считая, что сами дураки — не умеют писать заявки. А знания, которые необходимы для правильного написания заявки, находились у меня.
Люди потом прибегали через день: «А что мы неправильно написали-то?». Я объяснял, что где-то не поставили плюс или минус, забыли запятую. Они пишут заявку, я даю какую-то экспертизу, как работать в Oracle, и отправляю дальше в DBA, где сидят специально обученные люди, которые умеют выполнять эти заявки.
А они так же со мной работают, говорят: «Почему не указал тут основной показатель, не записал точку с запятой?». Заявку отменяем, цикл начинается заново. Сейчас за такое стыдно, но что поделать, раньше работали таким образом.
Артем: Затем мы начали меняться. Заявок было действительно много. Когда Сергей пришел в нашу команду, он стал следствием небольшой эволюции и трансформации. Я был автором достаточно большого количества регламентов разного типа заявок, потому что надо было как-то выживать. Вообще у нас вся трансформация происходила не из-за хайпа или моды, а из-за необходимости решать конкретные проблемы.
К примеру, изменения конфигурации приводят к тому, что у меня ломалась боевая и работала некорректно. Об этом я узнавал через сутки или ночью: бывало, что в шесть вечера что-то накатили, и до трех часов ночи всё это работало неправильно.
Проходили установки версии, перед которыми никто не собирался и не обсуждал, что делать, если что-то пойдет не так. Всем известная знаменитая многостраничная инструкция по установке передавалась буквально за полчаса до начала работ в эксплуатации. Нужно было что-то решать, и на тот момент мы нашли решение — адаптивное внедрение процессов ITIL.
Мы начали проверять, всё ли корректно накатилось после наката на боевую, нормально ли работает сервис и основные ключевые показатели. Мы начали встречаться перед установками версий. Вот тогда, собственно, было самое начало DevOps, когда команда разработки, которая передает дистрибутив, начала хотя бы встречаться с командой эксплуатации, обсуждать, что будет в ночных работах.
Сергей: А обсуждать было что: у нас было четыре страницы инструкций по установке — выполнить команду, выполнить план. Ее было практически невозможно написать без ошибок. Мы постоянно между разработкой ругались, что неправильно написали, прочитали, и всё в таком духе. Встречи иногда превращались в ад.
Артем: Пытались переехать с заявками в Confluence, так как в Word передавать неудобно — можно было что-то не так сформировать. В Confluence планировали всегда выкладывать актуальную версию со всеми изменениями.
Вставили кусок кода для наката на боевой. Confluence прожевал мета-разметку, выдал что-то другое некорректное, админ взял код, который превратился в лапшу и начал с ним работать — это была катастрофа.
Мы поняли, что как бы ни извращались со страничной инструкцией, всё это превращалось в полную ерунду, как бы она ни была оформлена.
Были важные предпосылки для затяжных простоев на ночных работах, что приводило к плохому взлету после установки, к косякам, и огромному количеству конфликтов между разработкой и эксплуатацией.
- Много человеческих ошибок при передаче изменений;
- Постоянный поиск виноватого;
- Скорость выноса новых модулей до 3 недель;
- Единые точки отказа (только вертикальное масштабирование), отсутствие балансировки;
- Плановый простой во время обновлений на 2 часа.
Предпосылки трансформации
Сергей: Было много изменений, мы постоянно лажали. Каждую неделю мы собирались, ругались, успокаивались. Этот процесс повторялся вечно, искали виноватого: «Это всё разработчики, пишущие кривой код, даже Java-модуль не могут передать».
Артем: А разработчики считали, что это элементарные вещи: вываливалась ошибка в логах — разберитесь, погуглите и поймете, что нужно исправить в конфигах.
Сергей: Также очень долго релизили новые продукты. Это как раз связано структурно: нам создавали заявку, мы должны были создать заявку на создание пользователя на сервере, потом создать схему. Затем начинался футбол заявками. Разработчики выдавали модули, а мы их не можем использовать, у нас же всё по регламенту.
Также мы очень долго ставились. Инструкция огромная, пока читаешь, пока делаешь, накат занимал часа два. Сами действия не выполнялись за секунду.
Артем: Там были и рутинные действия, к примеру, 30 Java-модулей. Во всех есть конфиг, в каждый конфиг нужно зайти и сделать изменения. Во-первых, можно сойти с ума делать одно и то же изменение: ненавидишь себя и всё остальное человечество. Во-вторых, вероятность совершения ошибки на 25-м конфиге становится крайне высока.
Сергей: Я помню, как получил предложение масштабироваться горизонтально. А у нас 150 модулей с разными конфигами: если ошибка в одной версии конфига, мне поставят вторую, а я и в ней ошибусь. Мы же не роботы, в конце концов.
Артем: Плановые простои времени обновления по 2 часа — это один из критичных факторов того, почему мы стали искать решение, как от этого уйти.
Дело в том, что мы предоставляем финансовые сервисы, процессинговые услуги. Мы работаем и на дальнее зарубежье. Тогда работали уже в 11-ти часовых поясах, в 2013 году у нас был всего один час окна, когда пользование сервисом было минимальным, количество клиентских обращений сводилось к минимуму, наступал штиль, и можно было что-то сделать.
Условно, мы могли проводить работы с часу до двух ночи. Два часа куда больше, чем это окно. Мы приближались к катастрофе, если бы не трансформация, потому что сейчас у нас физически окна нет.
Ответом на все эти проблемы у меня появилась идея, попытка разузнать, а что же такое DevOps.
В то время с HighLoad приехал наш коллега, я возился с внедрением CMBD, потому что мне нужно было, чтобы конфигурации не ломались и можно было хоть чем-то управлять. Он слушал доклад Саши Титова, который рассказывал про какой-то Chef. Вроде это тоже управление конфигурацией
В 2013 году я почитал про это всё, решил, что фигня какая-то и не то, что нужно. Мне надо контролировать, а они там код заставляют писать. Однако ситуация не менялась, проблемы копились и я заставил себя сесть дома и начать разбираться. Подумал, что в этом что-то есть, какое-то спасение.
И вот тогда я открыл для себя постулаты и ценности, что мы должны иметь одинаковое окружение, одинаковый сценарий выката и обновлений, что мы должны проверять эти сценарии, начиная с тестовой среды.
Появилась возможность минимизировать инструкцию и ручные действия, и всё максимально автоматизировать не просто разрозненными bash-скриптами, в которых потом другой админ ногу сломит.
Вот тогда я пришел с этой идеей, с первой декларацией того, что хочу получить. Это документ 2013 года, первый созданный в компании по поводу DevOps.
Сергей: Вот какая ключевая идея: уменьшить скорость выноса новых модулей, уменьшить количество ошибок при выносе на бой. То есть были конкретные цели, которых мы хотели достигнуть на первом этапе выпуска новых релизов.
Аргументов против было много. К примеру, страх, что автоматика все сломает: она непонятно работает, чужой код выполнять страшно, это же большой сервис, люди деньги через нас получают. Несерьезно.
Следующими подключились безопасники. Они прошлись по нам по полной: какие-то одинаковые stage! А у них идеальная картина мира: на флешке передавайте версии, подпишем их PGP-ключом, и всё будет замечательно — идеальный сервис. Мы с ними так долго работали, чтобы дойти до конца, только благодаря проектной деятельности у нас что-то получилось.
Артем: Здесь исходили из ценностей: вот на этом мы теряем деньги, вот этот простой недопустим.
Мы с ребятами придумали способ, как минимизировать эти потери. У вас есть вариант лучше это сделать? Если нет — молчите, если есть — критикуйте и предлагайте. Нечего предлагать? Тогда мы пробуем.
Шел процесс убеждения и продавливания: мы предлагали использовать свои идеи на ограниченном количестве систем.
Сергей: Нас попросили выписать все риски, как мы это будем выпускать. Нужно было согласовать с людьми, которые могли потерять деньги. Еще и программисты говорили: «Какой-то код писать, мы раньше нормально zip передавали, инструкции писали, еще какой-то дополнительный код писать ради выноса?!»
Артем: «Я пишу прикладной код бизнес-логики, я пользуюсь фреймворками, чтобы минимизировать любую ненужную часть кода. А вы просите еще код писать. Возьмите и вынесите, в конце-концов» — такие диалоги были на старте. Но тем не менее, всё это постепенно, через демонстрации и убеждения сработало.
Сергей: В первых итерациях мы сделали много важных решений с точки зрения структуры нашей компании и с точки зрения технологий. Прежде всего, внедрили Configuration management. Это избавило нас от проблем с выносом неправильной конфигурации с инструкцией в 10 страниц А4.
Тут начал проседать operations, и прикладные администраторы перешли в техническую дирекцию с разработчиками. Это дало чувство команды, чувство локтя. Мы стали понимать, что делаем продукт, а не выполняем непонятные заявки с желанием их отклонить — были конкретные цели.
Командная работа сближает, когда сидите рядом с людьми, когда видите, как они работают, когда они видят, как мы работаем. У нас даже появился диалог между командами: это первая искорка настоящего DevOps. Там была не техника, не какие-то новые технологии. C точки зрения техники, мы думали, что у нас вообще ничего не приживется, мы работали иначе, в другом мире.
Первая идея — Configuration Management вообще написать самим, разработчиков много. Потом мы вспомнили всё, что мы писали сами, и отказались — у нас всё фейлилось.
Артем: Я поправлю коллегу. Сергей не прав: всё, что мы пишем сами, отлично работало в нашей прикладной области, в чем мы сильны. А когда они пытались писать каких-то своих пауков для автоматического построения CMDB или какие-то самописные системы мониторинга для контроля бизнес-логики — да, здесь выходит система другого класса.
На этом этапе у нас получилось, что прикладные админы перешли из IT-дирекции в нашу техническую дирекцию. Как сказал Сергей, они начали чувствовать всю бизнесовую ценность, элементарно за счет меркантильных вещей.
Мы получили возможность платить им проектные премии за достижения, это вполне мотивировало. Поскольку они начали диалог, вынос модулей сократился из трех недель до недели с лишним, пошел определенный прогресс даже без какой-то глубинной автоматики.
Сергей: В этот момент, если мы что-то не понимали с заявкой, просили подойти разработчика: «Давай вместе решим и напишем, как правильно должна звучать заявка».
Артем: И на этой, условно, командной структуре мы начали двигаться в технику.
Сергей: Сейчас расскажем, как мы выбирали систему. Это было достаточно интересно. Прежде всего, мы попробовали Chef, по одной простой причине — мы знали гуру, который знает Chef. Потом мы попробовали Puppet, так как в то время Oracle объявил о поддержке Puppet.
Ansible тоже пробовали, но он обеим командам не понравился в качестве системы. Также были проблемы с безопасностью: Ansible в 2013 году очень сильно отличался от текущего.
Мы запустили параллельно два разных проекта с одинаковой функциональностью. И всё работало круто, возникло ощущение, что что-то тут неправильно и должна остаться одна. Как мы выбирали?
Артем: На Chef писали программисты, на Puppet писали админы. Идея была в чем: попробуем, потом сравним, где лучше и выберем. Но когда мы собрали, когда в итоге прошло время — двойственность начала создавать проблемы, потому что объем кода растет, он продолжает расти и всем всё нравится, разработчики пишут и автоматизируют.
Я всех собрал и спросил, на чем мы будем писать. Программисты сказали: «Нам на Chef очень нравится». А админы: «А нам на Puppet!». Это была полная жесть. Я сравнивал и понимал, что в текущем окружении и текущих параметрах нет объективного способа выбрать тот или иной продукт.
В итоге я сделал, как любят говорить в нашей стране, выборы с предсказуемым результатом. Некое «закрытое» голосование среди участников. Но не было фальсификации, было условное воздействие на , в результате которого был выбран Puppet. Я решил, что обиженных разработчиков успокою быстрее, чем обиженных админов. Другого критерия выбора просто не нашлось.
Сергей: В тот момент мы долго думали, как поставить бинарщину. На слайде можно увидеть фотографию с нашей доски и встречи. Решили, что нужно использовать какую-то систему пакетирования, а не свой велосипед. Опять победил разум.
На самом деле мы выбрали не RPM, а IPS — пакетный менеджер солярис. Мы импортировали сами с 11-й версии в десятку, которая стояла, и стали пользоваться. Отказываться от самописных bash-костылей и zip-ов в тот момент было самым правильным решением.
Артем: Это почему еще было важно: в рецепте результат появляется в виде изменения номера версии, он все дальше тянется от репозитория и становится нужным.
Когда нас приехали обучать DevOps, Chef, всем этим вещам, а мы подумали: «Сейчас расскажут, как передавать бинарщину», но нам ничего про это не сказали. Ответы обычно такие: «Каждый решает по-своему и выкручивается, как может». Поэтому поняли, что отраслевой ответ на это — «42», как из «Автостопом по галактике», ответ на главный вопрос вселенной.
Сергей: У нас также были долгие споры, как правильно построить CI/CD, что это такое. Вроде Configuration Management — одна утилита, взяли и поставили. А тут множество вариантов и выборов, долго спорили, разработчики делали свою систему, мы в эксплуатации делали свою для выноса.
На тот момент времени мы поняли, что идеального решения нет. Просто возьмем все, что наработали и вынесем. У разработчиков была полностью своя система для сборки, мы свою поставку сделали сами. Тут не было идеального выбора, и до сих пор работаем с разными командами по-разному. Идеала нет.
Также у нас большой стек, большая часть нашего кода запилена в базе данных: весь финансовый процессинг, в котором, к сожалению, сохраняется парадигма «чем ближе к данным, тем он работает быстрее». Oracle продает, Фаулер соглашается. Финансовые транзакции висят в PS/SQL, мы не нашли какого-то opensource-продукта, который помог бы решить нашу проблему с версионированием и поставкой. Возможно, он был, но мы стали писать свой инструмент.
Артем: У нас, на самом деле, большая проблема, потому что, как в начальном слайде упоминалось, Production — это большие вертикальные сервера. Соответственно, поднять на Stage такой же большой вертикальный сервер — это страшно дорого, и очень тяжело. Это еще полбеды.
Дело в том, что мы должны поднять примерно похожее по производительности окружение и наполнить схожими по объему, и, что не менее важно, кардинальности данными для того, чтобы наши тесты на Stage проходили корректно.
Вот здесь были очень тяжелые решения. Во-первых, что мы сделали с точки зрения скейлинга — поняли, что не сможем обеспечить на Stage такие же вертикальные машины, как на бою. Но мы можем в момент времени Х зафиксировать эталонные показатели запросов производительности системы на Stage-окружении и при выкате новых пакетов их сравнивать. Если они начинают аномально меняться, значит, у нас что-то поплыло и что-то не работает не так. Это одна проблема.
Дальше обнаружили проблему с переносом данных с боя на Stage для того, чтобы наполнить его тем же объемом данных. Нельзя, чтобы никто из людей, не имеющих по документам доступа к данным клиентов, имел к ним доступ.
Мы не имеем права в Stage лить персональные данные и банковскую тайну клиентов. Чтобы перенести эти данные, написал скрипты обфускации данных, чтобы они были не восстанавливаемы и не сопоставимы с реальными. При этом важно, что нельзя заменить всех ФИО на ааа bbb, потому что мы теряем кардинальность данные, и все наши проверки на Stage показывают некорректную информацию.
Поэтому мы писали этот скрипт еще и с прицелом на то, чтобы он генерировал некую условно рандомную кардинальность этих текстовых данных для того, чтобы наши запросы показывали адекватную, сопоставимую с боем картину, а мы могли понять изменения.
Мы уходим от абсолютного состояния производительности, мы смотрим изменения. Ситуация не ухудшилась по сравнению с предыдущей версией, которая, мы считаем, была неплоха по производительности.
Это вторая итерация. Наверное, самая ключевая фраза здесь, что здесь кончился проект. Не было никакого проекта DevOps. Здесь изначально был внутренний заказчик — я. Свой результат я получил: инструкция сократилась, ошибки при выносе версии сократились, боевая конфигурация стала изменяться, управляемая через Puppet, это стало контролируемо, понятно. Что я хотел, то и получил.
Сергей: Тут с твоей подачи произошли небольшие изменения. Опять перетекли обязанности из централизованного IT в техническую дирекцию.
Здесь стал полноценный OPS с рутом. Это помогло в действительности выполнить задачи с точки зрения выноса новых модулей. Мы стали быстрее выносить модули, после трех недель выполнение всего за три дня нам казалось идеальным. Результат был ощутимым: был драйв, команда начала сама генерировать идеи, что и как можно улучшить.
Что мы делали с точки зрения смежных подразделений: у нас команда 200+ человек, 150 разработчиков, 6 OPS-ов. Было много сопровождения, безопасников. Первое — пришло осознание, что самая лучшая идеальная заявка, которую не надо заводить. К этому стали идти, и стараться: если у человека есть возможность сделать что-то, не создавая заявку — всем хорошо. И она делается идеально быстро.
Артем: Вот здесь приведен пример, мы выносим оферту через git. Менеджер сам заходит и выносит оферту на бой.
Сергей: Мы нашли инструменты например Gitlab, нам понравилось, что человек может работать с графическим интерфейсом. Там есть кнопка «загрузить», пользователь может даже не понимать, что делает коммит на самом деле.
При этом у нас написаны скрипты для проверки контента, например что pdf — это pdf, проверка размера файла, и другая логика по выданным безопасниками правилам. Люди получили возможность обновлять эти документы, не создавая заявки. Нагрузка на ops снизилась.
Другая сложность была с тем, как вычислять такие моменты. В рутине непонятно, как искать проблемные места. Поэтому мы придумали свою шкалу и назвали ее «Шакалы».
Нас вдохновила старая картинка. Мы посчитали, что присваиваем каждой выполненной заявке количество шакалов, насколько она скучная и нудная и не хочется ее делать. В конце месяца считали, какие заявки набрали больше всего шакалов.
Садились всем подразделением и думали, как избавиться от этого безобразия. Как сделать так, чтобы не нужно было создавать на это заявки, это было круто и драйвило народ.
Следующий этап, где мы нашли способы автоматизации, — это боты. Мы освоили API Telegram, стали пилить боты для всех подряд, прежде всего, для себя. Сделали вывод последних триггеров.
Бизнесу понравилось: бывают ситуации, когда что-то лежит, все начинают звонить и спрашивать, что происходит. А так человек мог взять телефон, выбрать команду «инциденты» и прочитать последние инциденты. Люди стали подробнее вести инциденты, чтобы никто не звонил и не спрашивал о них.
Потом мы стали писать дополнительные фичи для получения получения информации, которая раньше была запросами в Jira. Бизнес хочет знать, был ли выполнен перевод: вводит номер, получает результат. Это тоже сильно облегчило жизнь с точки зрения заявок.
Артем: Параллельно мы совершили еще одну организационную трансформацию, но уже локальную, внутри отдела Сергея. Мы тогда очень заразились идеей с on call duty-инженером и благодаря Сергею сумели выстроить эту схему в отделе. Есть сидящий инженер на инцидентах, есть сидящий инженер на заявках, все остальные уничтожают шакалов, занимаются их отстрелом.
Работа с DEV
Сергей: Чем стало заниматься подразделение: появились перестановки, люди занимались не только шакалами, но и другими делами. Прежде всего, вели диалог с разработкой. Мы рассказывали новым командам, что такое DevOps, как его правильно готовить, учили CM.
Мы проходили путь от того, когда мы сами написали им рецепты, потом они научились их править, а затем писать самостоятельно. Также мы рассказываем про CI, помогаем настраивать pipeline и собирать пакеты. Мы помогаем строить безопасную среду для разработки.
Артем: С точки зрения CI, это всё очень важно. Параллельно я выступаю продукт-оунером, веду проекты, руковожу командами разработки. И здесь очень интересный кейс.
На небольших командах мы объединили функции эксплуатации, то есть Stage и Prod в лице одного подразделения. На этих небольших проектах, небольших продуктах, командах и инфраструктурах это получилось очень удобно. Ты насквозь видишь, как будешь катить бой.
Сергей: Когда боевой инженер настраивает тестовую среду, он делает ее один в один, зная, что она потом придет к нему, и ему с ней мучиться. Это важный психологический фактор, что нельзя халявить, лучше сделать всё сразу и нормально.
Что из этого получилось? Тут многие говорят, что DevOps-отдела нет, мы считаем, что у нас есть DevOps-отдел. Какие основные задачи отдела?
Он ходит, пропагандирует, рассказывает про DevOps. Все понимают, что это такое и как это готовить. Рассказывают и показывают, как новый продукт с базой данных можно выкатывать за пять минут.
Единственное наше ограничение — это безопасность, согласование схем. Когда у нас есть виртуалка и схемы согласованы, дальше все занимает пять минут. Всё полностью катится автоматически.
Артем: Когда у меня в августе был запуск нового продукта на бою, то есть полностью нового, мы вкатили за день 15-20 релизов без конфликтов и напряжения. Здесь ощущается ценность: это круто, когда спокойно релизнулся и идешь к следующему.
Сергей: Я расскажу о боли. Мы поддерживаем DRP-план восстановления с нуля. И когда не было автоматизации, мы туда копировали чуть ли не конфиги. Постоянно добавлялись новые модули, а план нужно постоянно актуализировать. С приходом DevOps и автоматизации план сократился: берем последнюю актуальную версию Git и дописываем в нее планы.
Этот план развертывания становится честным. Это поддерживается, в том числе, и тестовыми прогонами развертывания. Мы делаем тестовые прогоны, а на боевом осуществляем прогон с переключением на резерв. Вся рутинная история ушла. Это, кстати, помогло нам немного сдвинуть стек.
Раньше мы использовали SPARC Solaris, теперь появился x86 по простой причине: сегодня никто не пишет и не тестирует хипстерские приложения для Sparc. А мы используем например Haproxy, вместе с разработчиками мы пилили исправления багов для Solaris. Это нас достало, терпеть уже не хотелось. Мы выбрали платформу, на которой все тестируют продукты, и теперь на ней нормально работаем. Это тоже сдвинуло нас в сторону ускорения всего процесса.
Артем: Это вообще открыло ворота в новый мир, полный чудес. Потому что появление x86 нам позволило использовать действительно актуальные и полезные утилиты для наших задач. Более того, когда мы получили эту возможность, мы параллельно продвигались в сторону кластеризации.
Фактически, сейчас всё, кроме центрального и ядерного процессинга, у нас кластеризовано и отлично работает. Мы не паримся: простоя либо нет, либо он занимает максимум одну минуту, даже там, где кластера нет.
Единственное, где он остался и был не менее двух часов, — это миграция схем центрального процессинга. Сейчас она занимает восемь минут.
Сергей: На слайде новый документ, заявка с одной строчкой: сделать слияние в git. Больше нет тех десяти А4-листов.
Деплой новых модулей занимает до трех часов. Это какие-то сложные случаи, когда надо что-то сделать в Oracle, к примеру, получить виртуалку. Исчезли ошибки при выносах. Я не помню, чтобы кто-то что-то передал не так. Конечно, бывают какие-то шероховатости, но они все мелкие, несерьезные, очень быстро исправляются.
Что нам позволило достигнуть успеха? Прежде всего, мы не стали устраивать революцию здесь и сейчас. Я не говорил: «Нужно внедрить DevOps через три недели». Мы подошли к этому процессу методично, долго агитировали, рассказывали людям, капали на , говорили о целях, которых добиваемся.
Артем: Я отбивался от вопросов начальства: «Артем, когда DevOps?». Говорил, что не будет срока, пробуем в Prod, ничего не спрашивайте.
Сергей: С другой стороны, всё тоже очень круто. Мы не стали навязывать всем подразделениям используемые нами технологии. Компания большая, соседи смотрят, говорят: «Ну да, здорово, а у нас раз в полгода деплоится». Им это не нужно. Мы не ходим, не рассказываем, что у нас единственно правильное решение. Где-то не хотят использовать наш стек, для них мы запилили простые bash-скрипты, которые позволяют интегрироваться с другими командами.
Артем: Вот здесь я убежден в том, что сверху нельзя заставить внедрить DevOps. Это нереально для такого проекта.
Сергей: Мы проанализировали то, где теряем больше всего времени: сегодня мы больше всего теряем времени на безопасности.
Умеем быстро работать, быстро деплоиться, но согласовать схему развертывания — это какой-то ад. Сейчас посмотрели на это, напоминает то же самое, когда были абсолютно разные подразделения Dev и Ops. Сейчас у нас нет плана, думаем, как бы включить безопасность в наш процесс, чтобы они могли анализировать изменения.
Артем: Например, для этого можно использовать Merge, посмотреть, что изменилось в рецепте. Безопасник ведь тоже инженер.
Сергей: Зачастую наши формальные процессы не обеспечивает реальную безопасность. Когда мы проводим аудит, понимаем, что все процедуры прошли, а желаемого уровня безопасности не получили, при этом потрачено большое количество времени и ресурсов. Мы постоянно находим какие-то проблемы, которые произошли из-за плохой интеграции процессов безопасности и CI/CD.
С точки зрения OPS, у нас осталась проблема траты времени на CI и подгонку рецептов. Эта вещь уже начинает набирать «шакалов». Поэтому мы смотрим системы, чтобы представить фреймворки для разработчиков, мы смотрим в сторону Docker, Kubernetes, чтобы могли написать: «Ребята, есть инструменты, тут нет больших документов, можно унифицировать процесс поставки».
Мы хотим продвинуть эту идею, но опять сопротивляется безопасность. Говорят: «Какие-то у вас виртуальные сети, как это сервисы будут без файервола ходить?». Есть какие-то противоречия, но, я думаю, мы все равно победим.
Артем: У меня своя боль, я бы хотел ей закончить. У нас есть очень большая проблема: мы — компания, и мы не единственная такая компания, есть представители, которые находятся в такой же ситуации. Мы находимся под постоянным контролем регулятора, постоянно приходит Центробанк с аудитом. Мы проходим аудит, проходим внешне независимый аудит.
Аудитора винить сложно, он делает работу на основании стандартов, в которых написано, что физическая железка должна быть отдельной, не виртуальной машиной. Никаких контейнеров.
Ни один международный стандарт на текущий момент ни на йоту не подвинулся в сторону новых технологий. Там черная дыра. Они не замечают, что это большая проблема. Я не могу винить аудиторов, они проводят аудирование по стандартам. Им неоткуда это больше взять, но ни один стандарт не пытается в этом смысле меняться, куда-то трансформироваться и двигаться.
Мне нужно придумать, каким образом сейчас имеющуюся в компании картину подружить с вот этими ужасными словами, чтобы все было корректно и по-честному.
Если вы устали от лонгридов — рекомендуем послушать выпуск подкаста «Пятиминутка PHP» с нашими друзьями — Барухом Садогурским и Вячеславом Кузнецовым. Тренды DevOps, DecSecOps, победа Kubernetes и отчет State of DevOps 2018 by DORA.
А если хотите больше крутых докладов — приходите на конференцию DevOops 2018. Там будет и Барух, и Слава, и даже Джон Уиллис! Все спикеры и программа — на сайте.
Приятный бонус: до 1 октября билет на DevOops 2018 можно забронировать со скидкой.
Автор: Олег Чирухин
