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

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

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

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

«@jnewland:/disk_hogs»

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

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

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

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

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

Джастин Арбакл, будучи главным архитектором компании GE Capital, рассказывал: «Нам нужно было создать механизм, позволяющий командам легко соблюдать требования: государственные, региональные, отраслевые, описанные в десятках нормативных баз, распространяющиеся на тысячи приложений, работающих на десятках тысяч серверов в десятках дата-центров».

Созданный механизм получил название ArchOps. Этот механизм «позволял нашим инженерам быть строителями, а не каменщиками. Когда мы перевели стандарты проектирования в автоматизированные шаблоны, простые в использовании даже для новичка, консистентность оказалась побочным продуктом нашей работы».

Трансформируя процессы, осуществляемые вручную, в автоматизированный выполняемый код, мы делаем их доступными и полезными для всех, кто их использует. Арбакл заключает: «Уровень соблюдения требований в компании прямо пропорционален степени того, насколько эти требования переведены в код».

Если автоматизированный процесс — самый удобный способ достичь цели, то его будут использовать чаще и чаще, и можно даже подумать о том, чтобы сделать его общекорпоративным стандартом.

Общедоступный репозиторий исходного кода для всей компании — один из самых мощных механизмов распространения опыта по организации. Когда мы обновляем что-либо в таком репозитории (например, библиотеку общего пользования), изменения быстро и автоматически распространяются на все сервисы, использующие эту библиотеку.

Компания Google — один из самых ярких примеров использования репозитория, доступного всей организации. К 2015 г. в нем хранилось более миллиарда файлов и свыше двух миллиардов строк кода. Это хранилище кода используется каждым из 25 000 инженеров компании и покрывает все ее сервисы, включая Google Search, Google Maps, Google Docs, Google+, Google Calendar, Gmail и YouTube [155].

Один из ценных результатов такого подхода — то, что инженеры могут использовать разнообразный опыт всех сотрудников компании. Рэйчел Потвин, технический руководитель, возглавляющий группу по организации инфраструктуры для разработчиков, в интервью для журнала Wired рассказала, что у каждого инженера Google есть доступ к огромному объёму библиотек, где «практически все уже давно сделано до них».

Кроме того, как поясняет Эран Мессери, инженер команды по организации инфраструктуры для разработчиков в Google (Google Developer Infrastructure group), одно из преимуществ использования единого хранилища в том, что все пользователи имеют доступ к самой последней версии кода и ничего не нужно координировать.

Помимо исходного кода в едином репозитории можно хранить и другие вещи, фиксирующие знания и опыт компании, например:

• конфигурационные стандарты для библиотек, инфраструктуры и сред (рецепты Chef, декларации Puppet и так далее);

• инструменты развертывания;

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

• инструменты конвейера развертывания;

• инструменты мониторинга и анализа;

• руководства и стандарты.

Сохранение опыта и создание общего доступа через такое хранилище — один из самых мощных механизмов распространения знаний. Как пишет Рэнди Шуп, «самый мощный механизм для предотвращения сбоев в Google — это единый репозиторий. Когда кто-то отправляет туда свой код, новая сборка всегда будет использовать последние версии всего. Все собирается напрямую из исходников вместо того, чтобы динамически подключать во время выполнения необходимые компоненты. В каждый момент времени существует лишь одна версия библиотеки, она и подключается во время сборки приложения».

Том Лимончелли — соавтор книги The Practice of Cloud System Administration: Designing and Operating Large Distributed System s и бывший инженер SRE Google. В своей книге он утверждает, что ценность единого репозитория настолько высока, что это сложно выразить словами.

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

В Google у каждой библиотеки (например, libc, OpenSSL, а также библиотеки, разработанные самой компанией, например для поддержания многопоточности в Java) есть свой хранитель, ответственный за то, чтобы она не только компилировалась, но и успешно проходила тесты для всех зависящих от нее проектов, совсем как настоящий библиотекарь. Хранитель также отвечает за перевод каждого проекта со старой версии на новую.