Главная » Хабрахабр » История успеха, или DEV+DEVOPS+OPS

История успеха, или DEV+DEVOPS+OPS

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

Под катом — видео и текстовая расшифровка доклада. В основе материала — доклад-диалог Сергея Бердникова (Золотая Корона) и Артема Каличкина (ЦФТ) c октябрьской конференции DevOops 2017.

Мы с Артемом затеяли небольшую революцию-эволюцию. Сергей: Я руководитель отдела эксплуатации в нашей компании. Всё начиналось с революции, сейчас перешло в стадию эволюции.

Работа состоит из двух основных частей. Артем: Компания работает на финансовом рынке с 1992 года. Здесь мы выступаем в качестве вендора: мы разработали и продали вам коробку, а вы ее развернули и эксплуатируете. Первая часть — это разработка программного обеспечения, Core Banking, банковская бухгалтерия и так далее.

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

Про то, как мы приходили к истории с DevOps в этом процессинге, мы и расскажем. Мы с Сергеем работаем в процессинговой части нашей компании.

Компания изначально делала банковские продукты, соответственно, всё было привычное: вся инфраструктура SPARC only, собственные ЦОДы, всё ядро написано в Oracle. Сергей: Наследие у нас было полностью банковское. PL/SQL-код, много всяких штучек — это нелегко масштабировать.

Мы масштабировались только вертикально: покупали мощную железку, пользовались ей, пока не устареет, заменяли на новую и старую уводили в staging.

Мы резервировались через теплый резерв: есть ЦОД, и полностью вся скопированная структура — свичи, сервера, все один в один, болтик к болтику. Также писали много кода на Java.

Были отдельные технические дирекции Dev, дальше Firewalls с огнем. Тут можно увидеть, как выглядела вся структура с точки зрения процессов. То есть Dev-ы писали большую инструкцию, а IT Operations делилось на три подразделения:
Дальше было централизованное IT, которое занималось выносом, деплоем и так далее.

  • Прикладные администраторы, которые занимались деплоем. У них не было рута, на машинах были пользователи, они могли исполнять инструкции — это называется Monkey code.
  • Unix-администраторы, которые могли и умели конфигурировать, наливать железо и так далее.
  • Были отдельные специалисты по базам данных. А так как базы данных для нас — это основная цель, суть нашего существования долгое время, там происходило множество процессов.

Артем: DevOps здесь никакого на этом этапе еще нет, мы работали по регламентам, чем Сергей не был доволен.

Мы могли делать одну заявку три недели. Сергей: Я пришел в команду прикладных администраторов и помню, какие это были «прекрасные времена». А знания, которые необходимы для правильного написания заявки, находились у меня. Приходит заявка, в ней находили какую-то ошибку и отменяли, считая, что сами дураки — не умеют писать заявки.

Я объяснял, что где-то не поставили плюс или минус, забыли запятую. Люди потом прибегали через день: «А что мы неправильно написали-то?». Они пишут заявку, я даю какую-то экспертизу, как работать в Oracle, и отправляю дальше в DBA, где сидят специально обученные люди, которые умеют выполнять эти заявки.

Заявку отменяем, цикл начинается заново. А они так же со мной работают, говорят: «Почему не указал тут основной показатель, не записал точку с запятой?». Сейчас за такое стыдно, но что поделать, раньше работали таким образом.

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

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

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

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

Ее было практически невозможно написать без ошибок. Сергей: А обсуждать было что: у нас было четыре страницы инструкций по установке — выполнить команду, выполнить план. Встречи иногда превращались в ад. Мы постоянно между разработкой ругались, что неправильно написали, прочитали, и всё в таком духе.

В Confluence планировали всегда выкладывать актуальную версию со всеми изменениями. Артем: Пытались переехать с заявками в Confluence, так как в Word передавать неудобно — можно было что-то не так сформировать.

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

Мы поняли, что как бы ни извращались со страничной инструкцией, всё это превращалось в полную ерунду, как бы она ни была оформлена.

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

  • Много человеческих ошибок при передаче изменений;
  • Постоянный поиск виноватого;
  • Скорость выноса новых модулей до 3 недель;
  • Единые точки отказа (только вертикальное масштабирование), отсутствие балансировки;
  • Плановый простой во время обновлений на 2 часа.

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

Артем: А разработчики считали, что это элементарные вещи: вываливалась ошибка в логах — разберитесь, погуглите и поймете, что нужно исправить в конфигах.

Это как раз связано структурно: нам создавали заявку, мы должны были создать заявку на создание пользователя на сервере, потом создать схему. Сергей: Также очень долго релизили новые продукты. Разработчики выдавали модули, а мы их не можем использовать, у нас же всё по регламенту. Затем начинался футбол заявками.

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

Во всех есть конфиг, в каждый конфиг нужно зайти и сделать изменения. Артем: Там были и рутинные действия, к примеру, 30 Java-модулей. Во-вторых, вероятность совершения ошибки на 25-м конфиге становится крайне высока. Во-первых, можно сойти с ума делать одно и то же изменение: ненавидишь себя и всё остальное человечество.

А у нас 150 модулей с разными конфигами: если ошибка в одной версии конфига, мне поставят вторую, а я и в ней ошибусь. Сергей: Я помню, как получил предложение масштабироваться горизонтально. Мы же не роботы, в конце концов.

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

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

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

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

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

Мне надо контролировать, а они там код заставляют писать. В 2013 году я почитал про это всё, решил, что фигня какая-то и не то, что нужно. Подумал, что в этом что-то есть, какое-то спасение. Однако ситуация не менялась, проблемы копились и я заставил себя сесть дома и начать разбираться.

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

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

Это документ 2013 года, первый созданный в компании по поводу DevOps. Вот тогда я пришел с этой идеей, с первой декларацией того, что хочу получить.

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

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

Они прошлись по нам по полной: какие-то одинаковые stage! Следующими подключились безопасники. Мы с ними так долго работали, чтобы дойти до конца, только благодаря проектной деятельности у нас что-то получилось. А у них идеальная картина мира: на флешке передавайте версии, подпишем их PGP-ключом, и всё будет замечательно — идеальный сервис.

Артем: Здесь исходили из ценностей: вот на этом мы теряем деньги, вот этот простой недопустим.

У вас есть вариант лучше это сделать? Мы с ребятами придумали способ, как минимизировать эти потери. Нечего предлагать? Если нет — молчите, если есть — критикуйте и предлагайте. Тогда мы пробуем.

Шел процесс убеждения и продавливания: мы предлагали использовать свои идеи на ограниченном количестве систем.

Нужно было согласовать с людьми, которые могли потерять деньги. Сергей: Нас попросили выписать все риски, как мы это будем выпускать. Еще и программисты говорили: «Какой-то код писать, мы раньше нормально zip передавали, инструкции писали, еще какой-то дополнительный код писать ради выноса?!»

А вы просите еще код писать. Артем: «Я пишу прикладной код бизнес-логики, я пользуюсь фреймворками, чтобы минимизировать любую ненужную часть кода. Но тем не менее, всё это постепенно, через демонстрации и убеждения сработало. Возьмите и вынесите, в конце-концов» — такие диалоги были на старте.

Прежде всего, внедрили Configuration management. Сергей: В первых итерациях мы сделали много важных решений с точки зрения структуры нашей компании и с точки зрения технологий. Это избавило нас от проблем с выносом неправильной конфигурации с инструкцией в 10 страниц А4.

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

У нас даже появился диалог между командами: это первая искорка настоящего DevOps. Командная работа сближает, когда сидите рядом с людьми, когда видите, как они работают, когда они видят, как мы работаем. C точки зрения техники, мы думали, что у нас вообще ничего не приживется, мы работали иначе, в другом мире. Там была не техника, не какие-то новые технологии.

Потом мы вспомнили всё, что мы писали сами, и отказались — у нас всё фейлилось. Первая идея — Configuration Management вообще написать самим, разработчиков много.

Сергей не прав: всё, что мы пишем сами, отлично работало в нашей прикладной области, в чем мы сильны. Артем: Я поправлю коллегу. А когда они пытались писать каких-то своих пауков для автоматического построения CMDB или какие-то самописные системы мониторинга для контроля бизнес-логики — да, здесь выходит система другого класса.

Как сказал Сергей, они начали чувствовать всю бизнесовую ценность, элементарно за счет меркантильных вещей. На этом этапе у нас получилось, что прикладные админы перешли из IT-дирекции в нашу техническую дирекцию.

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

Сергей: В этот момент, если мы что-то не понимали с заявкой, просили подойти разработчика: «Давай вместе решим и напишем, как правильно должна звучать заявка».

Артем: И на этой, условно, командной структуре мы начали двигаться в технику.

Это было достаточно интересно. Сергей: Сейчас расскажем, как мы выбирали систему. Потом мы попробовали Puppet, так как в то время Oracle объявил о поддержке Puppet. Прежде всего, мы попробовали Chef, по одной простой причине — мы знали гуру, который знает Chef.

Также были проблемы с безопасностью: Ansible в 2013 году очень сильно отличался от текущего. Ansible тоже пробовали, но он обеим командам не понравился в качестве системы.

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

Идея была в чем: попробуем, потом сравним, где лучше и выберем. Артем: На Chef писали программисты, на Puppet писали админы. Но когда мы собрали, когда в итоге прошло время — двойственность начала создавать проблемы, потому что объем кода растет, он продолжает расти и всем всё нравится, разработчики пишут и автоматизируют.

Программисты сказали: «Нам на Chef очень нравится». Я всех собрал и спросил, на чем мы будем писать. Это была полная жесть. А админы: «А нам на Puppet!». Я сравнивал и понимал, что в текущем окружении и текущих параметрах нет объективного способа выбрать тот или иной продукт.

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

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

Мы импортировали сами с 11-й версии в десятку, которая стояла, и стали пользоваться. На самом деле мы выбрали не RPM, а IPS — пакетный менеджер солярис. Отказываться от самописных bash-костылей и zip-ов в тот момент было самым правильным решением.

Артем: Это почему еще было важно: в рецепте результат появляется в виде изменения номера версии, он все дальше тянется от репозитория и становится нужным.

Ответы обычно такие: «Каждый решает по-своему и выкручивается, как может». Когда нас приехали обучать DevOps, Chef, всем этим вещам, а мы подумали: «Сейчас расскажут, как передавать бинарщину», но нам ничего про это не сказали. Поэтому поняли, что отраслевой ответ на это — «42», как из «Автостопом по галактике», ответ на главный вопрос вселенной.

Вроде Configuration Management — одна утилита, взяли и поставили. Сергей: У нас также были долгие споры, как правильно построить CI/CD, что это такое. А тут множество вариантов и выборов, долго спорили, разработчики делали свою систему, мы в эксплуатации делали свою для выноса.

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

Oracle продает, Фаулер соглашается. Также у нас большой стек, большая часть нашего кода запилена в базе данных: весь финансовый процессинг, в котором, к сожалению, сохраняется парадигма «чем ближе к данным, тем он работает быстрее». Возможно, он был, но мы стали писать свой инструмент. Финансовые транзакции висят в PS/SQL, мы не нашли какого-то opensource-продукта, который помог бы решить нашу проблему с версионированием и поставкой.

Соответственно, поднять на Stage такой же большой вертикальный сервер — это страшно дорого, и очень тяжело. Артем: У нас, на самом деле, большая проблема, потому что, как в начальном слайде упоминалось, Production — это большие вертикальные сервера. Это еще полбеды.

Дело в том, что мы должны поднять примерно похожее по производительности окружение и наполнить схожими по объему, и, что не менее важно, кардинальности данными для того, чтобы наши тесты на 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-инженером и благодаря Сергею сумели выстроить эту схему в отделе. Артем: Параллельно мы совершили еще одну организационную трансформацию, но уже локальную, внутри отдела Сергея. Есть сидящий инженер на инцидентах, есть сидящий инженер на заявках, все остальные уничтожают шакалов, занимаются их отстрелом.

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

Также мы рассказываем про CI, помогаем настраивать pipeline и собирать пакеты. Мы проходили путь от того, когда мы сами написали им рецепты, потом они научились их править, а затем писать самостоятельно. Мы помогаем строить безопасную среду для разработки.

Параллельно я выступаю продукт-оунером, веду проекты, руковожу командами разработки. Артем: С точки зрения CI, это всё очень важно. И здесь очень интересный кейс.

На этих небольших проектах, небольших продуктах, командах и инфраструктурах это получилось очень удобно. На небольших командах мы объединили функции эксплуатации, то есть Stage и Prod в лице одного подразделения. Ты насквозь видишь, как будешь катить бой.

Это важный психологический фактор, что нельзя халявить, лучше сделать всё сразу и нормально. Сергей: Когда боевой инженер настраивает тестовую среду, он делает ее один в один, зная, что она потом придет к нему, и ему с ней мучиться.

Тут многие говорят, что DevOps-отдела нет, мы считаем, что у нас есть DevOps-отдел. Что из этого получилось? Какие основные задачи отдела?

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

Когда у нас есть виртуалка и схемы согласованы, дальше все занимает пять минут. Единственное наше ограничение — это безопасность, согласование схем. Всё полностью катится автоматически.

Здесь ощущается ценность: это круто, когда спокойно релизнулся и идешь к следующему. Артем: Когда у меня в августе был запуск нового продукта на бою, то есть полностью нового, мы вкатили за день 15-20 релизов без конфликтов и напряжения.

Мы поддерживаем DRP-план восстановления с нуля. Сергей: Я расскажу о боли. Постоянно добавлялись новые модули, а план нужно постоянно актуализировать. И когда не было автоматизации, мы туда копировали чуть ли не конфиги. С приходом DevOps и автоматизации план сократился: берем последнюю актуальную версию Git и дописываем в нее планы.

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

А мы используем например Haproxy, вместе с разработчиками мы пилили исправления багов для Solaris. Раньше мы использовали SPARC Solaris, теперь появился x86 по простой причине: сегодня никто не пишет и не тестирует хипстерские приложения для Sparc. Мы выбрали платформу, на которой все тестируют продукты, и теперь на ней нормально работаем. Это нас достало, терпеть уже не хотелось. Это тоже сдвинуло нас в сторону ускорения всего процесса.

Потому что появление x86 нам позволило использовать действительно актуальные и полезные утилиты для наших задач. Артем: Это вообще открыло ворота в новый мир, полный чудес. Более того, когда мы получили эту возможность, мы параллельно продвигались в сторону кластеризации.

Мы не паримся: простоя либо нет, либо он занимает максимум одну минуту, даже там, где кластера нет. Фактически, сейчас всё, кроме центрального и ядерного процессинга, у нас кластеризовано и отлично работает.

Сейчас она занимает восемь минут. Единственное, где он остался и был не менее двух часов, — это миграция схем центрального процессинга.

Больше нет тех десяти А4-листов. Сергей: На слайде новый документ, заявка с одной строчкой: сделать слияние в git.

Это какие-то сложные случаи, когда надо что-то сделать в Oracle, к примеру, получить виртуалку. Деплой новых модулей занимает до трех часов. Я не помню, чтобы кто-то что-то передал не так. Исчезли ошибки при выносах. Конечно, бывают какие-то шероховатости, но они все мелкие, несерьезные, очень быстро исправляются.

Прежде всего, мы не стали устраивать революцию здесь и сейчас. Что нам позволило достигнуть успеха? Мы подошли к этому процессу методично, долго агитировали, рассказывали людям, капали на мозги, говорили о целях, которых добиваемся. Я не говорил: «Нужно внедрить DevOps через три недели».

Говорил, что не будет срока, пробуем в Prod, ничего не спрашивайте. Артем: Я отбивался от вопросов начальства: «Артем, когда DevOps?».

Мы не стали навязывать всем подразделениям используемые нами технологии. Сергей: С другой стороны, всё тоже очень круто. Им это не нужно. Компания большая, соседи смотрят, говорят: «Ну да, здорово, а у нас раз в полгода деплоится». Где-то не хотят использовать наш стек, для них мы запилили простые bash-скрипты, которые позволяют интегрироваться с другими командами. Мы не ходим, не рассказываем, что у нас единственно правильное решение.

Это нереально для такого проекта. Артем: Вот здесь я убежден в том, что сверху нельзя заставить внедрить DevOps.

Сергей: Мы проанализировали то, где теряем больше всего времени: сегодня мы больше всего теряем времени на безопасности.

Сейчас посмотрели на это, напоминает то же самое, когда были абсолютно разные подразделения Dev и Ops. Умеем быстро работать, быстро деплоиться, но согласовать схему развертывания — это какой-то ад. Сейчас у нас нет плана, думаем, как бы включить безопасность в наш процесс, чтобы они могли анализировать изменения.

Безопасник ведь тоже инженер. Артем: Например, для этого можно использовать Merge, посмотреть, что изменилось в рецепте.

Когда мы проводим аудит, понимаем, что все процедуры прошли, а желаемого уровня безопасности не получили, при этом потрачено большое количество времени и ресурсов. Сергей: Зачастую наши формальные процессы не обеспечивает реальную безопасность. Мы постоянно находим какие-то проблемы, которые произошли из-за плохой интеграции процессов безопасности и CI/CD.

Эта вещь уже начинает набирать «шакалов». С точки зрения OPS, у нас осталась проблема траты времени на CI и подгонку рецептов. Поэтому мы смотрим системы, чтобы представить фреймворки для разработчиков, мы смотрим в сторону Docker, Kubernetes, чтобы могли написать: «Ребята, есть инструменты, тут нет больших документов, можно унифицировать процесс поставки».

Говорят: «Какие-то у вас виртуальные сети, как это сервисы будут без файервола ходить?». Мы хотим продвинуть эту идею, но опять сопротивляется безопасность. Есть какие-то противоречия, но, я думаю, мы все равно победим.

У нас есть очень большая проблема: мы — компания, и мы не единственная такая компания, есть представители, которые находятся в такой же ситуации. Артем: У меня своя боль, я бы хотел ей закончить. Мы проходим аудит, проходим внешне независимый аудит. Мы находимся под постоянным контролем регулятора, постоянно приходит Центробанк с аудитом.

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

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

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

Тренды DevOps, DecSecOps, победа Kubernetes и отчет State of DevOps 2018 by DORA. Если вы устали от лонгридов — рекомендуем послушать выпуск подкаста «Пятиминутка PHP» с нашими друзьями — Барухом Садогурским и Вячеславом Кузнецовым.

Там будет и Барух, и Слава, и даже Джон Уиллис! А если хотите больше крутых докладов — приходите на конференцию DevOops 2018. Все спикеры и программа — на сайте.

Приятный бонус: до 1 октября билет на DevOops 2018 можно забронировать со скидкой.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Теория счастья. Случайности неслучайны

Продолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь ...

Снежинки в стилистике StarWars своими руками (upd. 2018)

Для изготовления снежинок вам потребуется: Файл со схемой.2. 1. Ножницы.4. Принтер (думаю лазерный будет предпочтительней).3. Бумага.5. Скальпель.5. Лично мое мнение — при печати на стандартной офисной бумаге плотностью 80г/м2 становится не очень удобно вырезать (все-таки при складывании бумаги получается толстый ...