Как Корпорация Майкрософт предоставляет программное обеспечение с помощью DevOps

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

Для реализации процессов доставки DevOps корпорация Майкрософт приняла следующие инициативы:

• Сосредоточьтесь на мышлении организации и темпе, ориентируясь на результативность.
• Формируйте автономные, подотчетные команды, которые имеют, тестируют и предоставляют функции.
• Перейдите вправо на тестирование и мониторинг систем в рабочей среде.

Фокус на выполнении

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

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

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

Полностью автоматизировать конвейеры

Многие команды по улучшению могут сразу извлечь пользу, полностью автоматизировав конвейеры от хранилища кода до рабочей среды. Автоматизация включает конвейеры выпуска с непрерывной интеграцией (CI), автоматизированным тестированием и непрерывной доставкой (CD).

Команды могут избежать развертывания, так как это трудно, но реже они развертываются, тем сложнее. Чем больше времени между развертываниями, тем больше проблем сложилось. Если код не является свежим, существует задолженность по развертыванию.

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

Использование встроенных инструментов

Корпорация Майкрософт использует систему управления выпусками, которые они создают, и отправляет ее клиентам. Одна инвестиция повышает производительность команды и продукты Майкрософт. Использование вспомогательной системы снизит скорость разработки и доставки.

Автономия команды и подотчетность

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

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

Приоритет функций

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

Использование микрослужб

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

Работа в основном

Инженеры работали в отдельных областях. Сложность объединения на каждой ветке росла, пока инженер не пытался интегрировать свою ветку в основную. Чем больше команд и инженеров были, тем больше интеграция стала.

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

Использование флагов компонентов

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

Тестирование в рабочей среде

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

Тестирование инструментов и метрик

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

Тестирование шаблонов устойчивости

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

Выбор правильных метрик

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

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

Использование метрик для руководства по работе

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

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

Рекомендации по доставке

• Это никогда не прямая линия, чтобы добраться от A до B, ни является B концом.
• Всегда будут неудачи и ошибки.
• Рассматривать неудачи как возможность для обучения и адаптации тактики в процессе.
• Со временем каждая команда развивается свои методики DevOps, опираясь на опыт и корректируя их в соответствии с изменяющимися потребностями.
• Ключ заключается в том, чтобы сосредоточиться на доставке ценности как конечным пользователям, так и самому процессу доставки.