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

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

Скотт так описывал одну из неприятных сторон этого решения: «Вы начали всем видимую деятельность, весь мир смотрит на вас, и тут мы заявляем руководству, что не собираемся делать ничего нового, так как все инженеры будут работать над проектом [InVersion] два следующих месяца. Это пугает».

Однако Вэнс рассказал о значительном положительном результате операции InVersion. «LinkedIn создал целый пакет программного обеспечения и инструментов, помогающих разрабатывать код для его сайта. Вместо того чтобы ждать несколько недель, пока новые функции проделают свой путь на главный сайт LinkedIn, инженеры могли разработать новый сервис, использовать ряд автоматизированных систем изучения кода с целью поиска ошибок в коде и проблем при взаимодействии сервиса с существующими функциями и запустить его прямо на сайте LinkedIn… Инженерная служба LinkedIn теперь выполняет крупные обновления сайта трижды в день». За счет создания более безопасной системы создаваемая продукция обеспечивает меньший объем сверхурочной работы по ночам и большее количество времени для разработки новых, инновационных функций.

Как писал Джош Клемм в статье о масштабировании в LinkedIn, оно «может быть измерено через многочисленные аспекты, в том числе организационные… Операция InVersion позволила всей инженерной организации сосредоточить усилия на улучшении и инструментов, и разворачивания, и инфраструктуры, и производительности труда разработчиков. Она была успешной в деле предоставления инженерам гибкости, в которой мы нуждались для создания масштабируемых новых продуктов, имеющихся у нас сегодня… В 2010 г. мы уже имели более 150 отдельных сервисов. Сегодня у нас есть более 750 сервисов».

Кевин Скотт заявил: «Ваша задача как инженера и ваши цели как технологической команды — помочь компании выиграть. Если вы руководите группой инженеров, лучше, чтобы вы нацеливались на перспективы, намечаемые CEO. Ваша задача — выяснить, в чем же нуждается компания, бизнес, рынок, конкурентоспособная производственная среда. Примените это знание к вашей инженерной группе, чтобы ваша компания смогла выиграть».

Дав компании LinkedIn возможность выплатить накапливавшийся в течение почти десятилетия технический долг, проект InVersion обеспечил стабильность и безопасность следующего этапа роста компании. Вместе с тем он потребовал двух месяцев общей сфокусированности на нефункциональных требованиях в ущерб всем ранее обещанным в ходе IPO функциональным возможностям. Сделав поиск и устранение проблем частью повседневности, мы управляем техническим долгом, чтобы избежать ситуации, когда вдруг окажемся «на грани исчезновения».

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

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

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

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

Действуя таким образом, разработчики и IT-отдел могут в конечном счете создать общую очередность работ, вместо того чтобы каждый использовал свою систему (например, разработчики используют JIRA, а отдел эксплуатации — ServiceNow). Значительное преимущество такого решения в том, что инциденты на производстве регистрируются в той же системе, что и текущая работа, и очевидно, что при наличии в системе инцидентов следует прекратить другую деятельность, особенно если мы используем доску канбан.

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

Другие технологии, укрепляющие общие цели, — чаты, например IRC, HipChat, Campfire, Slack, Flowdock и OpenFire. Чат позволяет быстро обмениваться информацией (в отличие от заполнения форм, обрабатывающихся с помощью предварительно определенных рабочих процессов), дает возможность пригласить других специалистов по мере необходимости и вести журналы истории, заполняющиеся автоматически. Они могут быть проанализированы при разборе событий.

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

Однако среда быстрых коммуникаций, предоставляемая чатом, может иметь и обратную сторону. Как отмечает Райан Мартенс, основатель и технический директор компании Rally Software, «в чате, если кто-либо не получает ответа через пару минут, считается нормой, что можно отправить вопрос снова и делать это, пока вы не получите необходимый ответ».