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

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

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

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

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

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

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

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

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

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

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