Джин Ким - Руководство по DevOps

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

Эта методика впервые была опробована в GitHub, где она стала известна под названием ChatOps. Главной целью было использовать автоматизированные инструменты прямо в разговорах чатов, создавая прозрачность и документируя текущую работу. Как пишет Джесс Ньюлэнд, системный инженер GitHub, «Даже если вы новичок, вы можете посмотреть на логи чатов и увидеть, как все было сделано. Вы как будто все время занимались парным программированием со всей командой».

Они создали Hubot, приложение, взаимодействовавшее с командой эксплуатации в их чатах, где можно было выполнять действия с помощью команд прямо из беседы (например, @hubot deploy owl to production [152]). Результаты выполнения также отображались в чате.

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

• все видят всё, что происходит;

• новые инженеры в первый же рабочий день могли видеть, как выглядит повседневная работа и как ее выполняют другие;

• сотрудники чаще просили о помощи, когда видели, что остальные помогают друг другу;

• новые знания внутри компании накапливались гораздо быстрее.

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

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

Это также очень эффективный способ распространения знаний по компании. В GitHub все сотрудники, занимавшиеся эксплуатацией, работали удаленно. Более того, все инженеры эксплуатации жили в разных городах. Как вспоминает Марк Имбриако, бывший директор по эксплуатации GitHub, «в GitHub не было материального кулера. Кулером был чат» [153].

Через Hubot можно было запускать разные инструменты автоматизации, используемые в Github, такие как Puppet, Capistrano, Jenkins, resque (библиотека на основе Redis для создания фоновых процессов) и graphme (инструмент для создания графиков в Graphite).

С помощью Hubot можно было проверять работоспособность сервисов, развертывать код в производственную среду и блокировать оповещения, когда сервисы переходили в профилактический режим. Повторяющиеся действия, например smoke-test при сбое развертывания, выведение серверов эксплуатации из работы, возврат к исходной ветке для front-end-сервисов или извинения инженерам, вызванным в нерабочее время, тоже стали возможными действиями в Hubot [154].

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

Типичный разговор в чате мог выглядеть так:

«@sr: @jnewland, как получить список больших репозиториев? что-то вроде disk_hogs?»

«@jnewland:/disk_hogs»

Ньюлэнд отмечает: некоторые вопросы, которые раньше часто задавали во время работы над проектом, теперь звучат очень редко. Например, инженеры могут спрашивать друг у друга: «Как там развертывание?», или «Ты проведешь развертывание или я?», или «В каком состоянии загрузка?»

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

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

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