Что такое методология DevOps и кому она нужна / Хабр

С чего начать, чтобы стать devops engineer?

Начните с полезных статей:

Посмотрите видео на канале ADV-IT, где подробно расписано, что учить и в каком порядке:

Получите более уверенные знания из нескольких книг:

Философия devops. искусство управления it

IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps.

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

Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.

Continuous delivery. практика непрерывных апдейтов

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

Эберхард Вольф познакомит вас с популярными передовыми технологиями, облегчающими труд разработчиков: Docker, Chef, Vagrant, Jenkins, Graphite, ELK stack, JBehave и Gatling. Вы пройдёте через все этапы сборки, непрерывной интеграции, нагрузочного тестирования, развёртывания и контроля.

И помните, что от этого специалиста требуется тщательная проработка целого ряда вопросов.

Будьте одержимы клиентом

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

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

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

• Потом мы сказали — окей код готов только тогда, когда софт «живёт в продакшне», им все пользуются. И всё вроде бы прекрасно, кажется, что на этом можно было бы закончить эволюцию. На самом деле нет.

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

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

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

Затем мы смотрим, как реагируют люди, довольны ли наши клиенты. Если недовольны, значит фича будет изменяться до тех пор, пока люди не будут ей довольны. А если совсем недовольны, возможно, мы просто не будем эту фичу дальше разрабатывать и поддерживать.

Фидбек от клиентов мы получаем всеми возможными способами: на Stack Overflow, на форумах Azure (ранее MSDN) и ещё на всяких разных площадках. Проектные, продуктовые и программные менеджеры активно собирают обратную связь на свои продукты.

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

В самом продукте, даже если вы им пользуетесь бесплатно, можно дать фидбек. И у нас есть «чемпионы по клиентам» (customer champions) — крупным клиентам назначается сотрудник из инженерного отдела, который разговаривает с ними, допустим, раз в месяц. Такие сотрудники могут выступать адвокатами клиентов и влиять на продукт.

Дополнительные ответы экспертов

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

Я бы сказал, что чёткого разделения между системным и DevOps-инженером нет — и те и другие отвечают за работу продукта на производстве. Однако акцент работы первого может быть смещён в сторону поддержки работоспособности продукта уже в готовом окружении, в то время как DevOps-инженер больше ориентирован на подготовку этого самого окружения.

Каждый день DevOps-инженер оперирует большим количеством инструментов. Их можно условно разделить на разные группы — к примеру, те, что связаны со средой непрерывного развёртывания (CI/CD-tools), с автоматической конфигурацией, мониторингом, облачной инфраструктурой и др.

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

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

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

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

• проектирование инфраструктуры;
• настройку, поддержку и управление облачными сервисами;
• управление конфигурацией рабочих, тестовых, production-серверов;
• управление непрерывной интеграцией CI/CD (в этом пункте на ум сразу приходят инструменты Jenkins/Bamboo/TeamCity);
• миграция приложений в облако;
• мониторинг инфраструктуры и приложений;
• управление поставкой ПО.

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

Начнём с того, что DevOps — подход, а не инженер. Роль DevOps в проекте основополагающая. Проект и всё, что с ним связано, базируется на DevOps-процессах. DevOps — это связать вместе разные части всей экосистемы (Dev, QA, Ops, Sec) и автоматизировано обеспечить SDLC.

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

Чем DevOps отличается от сисадмина? Практически всем. Сисадмин отвечает за конкретные задачи: управление доступом пользователей, настройка сетевой составляющей инфраструктуры, почтовые/DNS-серверы, VMS, обновления ОС и т. д. В сложной экосистеме и процессах, связанных с проектом и SDLC, это малая часть задач, относящихся к Ops.

Основными обязанностями ДевОпс можно назвать следующие основополагающие процессы в жизнедеятельности продукта:

• CI/CD (Jenkins, Teamcity, Octopus, Gitlab CI и т. д.);
• Automation (tests automation, tasks automation, updates automation, backups automation, ALL automation);
• IaC (Terraform, Cloud Native: ARM, Cloud Formation и т. д.);
• Alerting/Monitoring;
• Backup/Restore;
• Disaster Recovery;
• Security Management (DevSecOps);
• Release Management и многое другое.

Каждый пункт можно разложить на десятки подзадач. Счёт технологий идёт на сотни. База выглядит вот так:

• CI/CD tools (f.e. Jenkins);
• Cloud (AWS/Azure/GCP);
• IaC (Terraform);
• Containers (Docker, K8s);
• Scripting Languages (PS, Python, Bash).

Зачем microsoft трансформация?

Ещё один интересный вопрос, если мы говорим про Microsoft: зачем нужна была трансформация?

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

Но зачем Microsoft было всё менять, если у них и так всё было хорошо и они прекрасно себе зарабатывали деньги? Лично я считаю, что Microsoft как раз и находится в списке десяти крупнейших компаний мира, так как в ней не боятся всё менять и не думают, что если они делали что-то вчера, то и завтра это будет продолжать работать.

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

Остановлюсь на Microsoft. Там все выглядело примерно так: 

Между разными отделами постоянно шла какая-то война. Почему? Потому что были какие-то мотивы, чтобы люди не сотрудничали, а показывали свои личные результаты или результаты своего отдела. Давайте подумаем: допустим, если я глава Office, а вы глава Windows, то я не хочу полагаться на какие-то инструменты, которыми вы пользуетесь, на инструменты CI/CD. Почему?

И это приводило к тому, что каждый отдел разрабатывал свои собственные инструменты CI/CD и собственные тестовые фреймворки. И каждый отдельный разработчик делал новый фреймворк или инструмент, вносил это достижение в свой отчет, и в конце года на основе отчета ему присуждали бонусы и т. д.

Тут Microsoft очень повезло — пришел Сатья Наделла, который стал CEO. У Наделлы инженерный бэкграунд, 20 лет он работал в инженерных отделах прежде чем стать топ-менеджером. Он сказал о том, что мы не эффективно расходуем время, раз за разом создавая одни и те же инструменты, которыми пользуются люди.

Eсли вы читали книгу Джина Кима Unicorn Project, то знаете, что в большинстве компаний происходит не так. В них руководители больше всего хотят новые фичи, и не очень понимают, почему нужно работать над повышением продуктивности или сокращением технического долга. Но как я уже сказала, Microsoft в этом случае очень повезло.

Так появилась единая инженерная система (1ES), на которой теперь базируются все инженеры в Microsoft. На данный момент около 105-110 тысяч инженеров (сегодня в Microsoft более 150 тысяч работников) пользуются платформой DevOps, то есть одной инженерной системой.

Если мы хотим узнать, насколько единая инженерная система полезна для Microsoft, то можно провести такую аналогию: если мы сохраняем всем инженерам компании одну секунду в день, это равнозначно найму еще четырех человек в Microsoft. Если мы сохраняем им одну минуту, то это эквивалентно найму 163 человек в Microsoft.

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

Хочу показать таймлайн  Microsoft. В 2008 году началась работа над Team Foundation Server (предшественником MS Azure DevOps), и в 2022 году вышла первая версия TFS на DVD. Первая версия, которая была записана на DVD, с трудом скомпилировалась, с трудом прошла все тесты, и была записана с большим трудом.

Но кроме этого ещё и клиентам нужно было нанять пару консультантов, которые помогли бы установить TFS. Просто так из коробки он не работал, его нужно было хорошенько доработать напильником, чтобы убрать все шероховатости, и всё нормально начало работать.

Выпустить первую версию заняло два года — с 2008 по 2022, и потом ещё два года — до VSTS Preview. И из этого цикла, который продолжался два года до релиза софта, мы на сегодня перешли к тому, что сейчас Microsoft публикует Azure DevOps и другие продукты несколько раз в день.

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

Visual Studio Team Services вышел в 2022 году, а потом был переименован в Azure DevOps. В 2022 году впервые появилась организация Microsoft на GitHub, и там начали размещать разные опенсорс-проекты. Опенсорсные проекты у MS появились ещё до приобретения на GitHub — в 2022 году их число составляло 400.

В 2022 году появился VS Code, который сразу был с открытым исходным кодом, и это тоже важная веха в Microsoft — компания решила запустить  не коммерциализированный продукт, а сразу опенсорсный.

В 2022 году Microsoft присоединилась к Linux Foundation, что очень многих удивило. В 2022 году произошла ещё одна важная вещь — Windows перешел на Git. До этого код Windows хранился в нашей собственной системе контроля кода, которая называлась TFVC (существует до сих пор). В 2022 году Windows перешёл на Git, который изначально был создан для поддержки Linux.

В 2022 году Microsoft приобрела GitHub. Вот почему я тут перед вами в футболке с логотипом GitHub. На данный момент (декабрь 2020 года) у нас почти 9 тысяч опенсорс-проектов в Microsoft (суммарно за 10 лет), и 25 тысяч из примерно 150 тысяч работников в Microsoft активно работает над опенсорсом. Например, сотрудничает с Kubernetes и другими опенсорс-проектами, которыми пользуется множество людей.

Измените способ сотрудничества, разработки и доставки

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

Inner source сейчас развивается и постепенно начинает внедряться в разные крупные  компании. Из опенсорса нам знакомо такое понятие, как воронка вкладов (contribution funnel): большинство людей будут просто пользоваться вашим кодом, то есть качать пакеты или, может быть или заведут свой форк.

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

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

С выходом GitHub Codespaces это стало проще. В Codespaces можно работать, можно всё отконфигурировать и сделать всё ещё проще для людей. Также важно создать список «good first contribution» (хороший первый вклад), чтобы новые люди в проекте знали, с чего им начать и какой баг можно легко пофиксить.

Внутри Microsoft 90% пулл-реквестов поступает от участников той же команды. Но потом 9% — из соседней команды и 1% от вот всех запросов приходит из команд, которые могут быть совершенно в другом отделе организации.

Что всё это значит? Почему InnerSource — это классно? Например, я работаю над UI для какого-то проекта, а у него есть API, который я беру из другого отдела. Мне нужны какие-то данные из этого API, а в этом API, например, мне не хватает какого-то параметра.

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

Но если есть InnerSource, то всё будет расписано: как делать вклад в проект, как можно сделать пулл-реквест в ваш API  и т. д., какие инструменты для этого нужны.

Тогда я могу посмотреть ваш код и ваши процессы разработки, и просто добавить этот новый параметр в ваш API. Ваша команда теперь может проверить, что он проходит все тесты, посмотреть код-ревью, убедиться, что всё соответствует вашим стандартам, а потом его смёрджить, и тогда я сама себя разблокирую. Так в InnerSource появляется общая возможность продвигаться быстрее.

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

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

Краткая история devops

Затем начали появляться совершенно новые подходы.

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

В 2008 году Патрик Дебуа на одной из конференций рассказал людям про Agile для инфраструктуры, и с тех пор начались разговоры о том, как программисты (Dev)  могут сотрудничать с эксплуатацией (Ops). Вместо того чтобы перекидывать баги друг на друга и говорить, что Dev нужны только новые фичи, а Ops — чтобы всё было стабильно, люди начали говорить о сотрудничестве, и что их общая цель — поставлять работающее программное обеспечение клиентам или пользователям. И на этом всё должно фокусироваться.

Прим. редактора: если захочется узнать об истоках DevOps подробнее — у нас об этом был отдельный хабрапост.

Кроме того, в 2009 году произошло еще несколько вещей. 

Джон Оллспоу, работавший тогда в Flickr, на конференции Velocity рассказал, что Flickr публикует код в продакшн 10 раз в день. Ему почти никто не поверил. Или люди просто говорили: «Окей, у вас стартап и очень много денег, поэтому вы можете такое себе позволить. А вот в нашей организации такое совершенно нереально сделать».

Тогда же, в 2009 году в бельгийском Генте впервые была проведена конференция DevOpsDays, там было некоторое количество людей, которые обсуждали, что можно улучшить в нашей практике публикации кода в продакшн, чтобы всем лучше работалось.

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

К 2009 году на платформе GitHub было уже было 50 тысяч программистов, которые сотрудничали над опенсорс-проектами. В 2022 году появился Microsoft Azure, который на тот момент назывался Windows Azure. Это тоже пример трансформации: на данный момент свыше 50% виртуальных машин на Microsoft Azure работают на Linux.

И начался он с того, что сначала были платформы как облачные услуги (platform as a service cloud services), которые были нацелены на программистов. Инфраструктуры там почти не было: всё было направлено на то, чтобы вы могли нажать одну кнопочку, и из Visual Studio код мог сразу уйти в облако и жить там на каком-то сервере.

Так вышло, что из Dev я стала Ops, (или DevOps как мы теперь говорим, хотя мы вначале и не хотели чтобы DevOps стал названием должности и названием продукта, но и то и другое случилось), так как мы начали работать с Azure Cloud ещё в 2022 году и постепенно, когда Azure Cloud начал добавлять инфраструктуру, мы начали заниматься и инфраструктурой вдобавок к тому, чтобы заниматься разработкой.

В 2022 году вышла книга «Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ» Джеза Хамбла и Дэвида Фарли (Вильямс, 2022). И по сей день эта книга фундаментальнаяв отрасли. Очень советую ее прочитать или хотя бы пролистать, если вы с ней не знакомы.

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

В 2022 году появилось такое слово, как DevSecOps, стали говорить о том, чтобы интегрировать безопасность вместе с DevOps. У нас употребляется термин shift security left, то есть чем раньше мы интегрируем безопасность приложения в цикл разработки, тем лучше, чтобы как можно быстрее выявить баги, связанные с безопасностью. Над этим очень серьёзно работает GitHub, поскольку на данный момент это очень большая, ещё не разрешенная проблема.

В 2022–2022 годах начала появляться идея об инфраструктуре как о коде (infrastructure as code), что можно не только писать код, добавлять контроль версий и потом публиковать CI/CD в продакшн, но и делать так же с инфраструктурой. Можно написать какую-то автоматизацию, которая будет публиковать в продакшн даже  виртуальные машины, чтобы они могли тоже автоматизироваться, быть в системе контроля версий и т. д.

В 2022 году возникла идея об SRE (site reliability engineering), то есть об обеспечении надежности всех уровней системы, и был проведен первый SREcon. Люди начали говорить о том, как сделать код более надёжным и как фокусироваться на SLA (Service Level Agreement)

В 2022 году Microsoft выпустила Azure Machine Learning — платформу машинного обучения в облаке. Мы работаем над тем, чтобы это становилось проще сделать, решаем нетривиальные проблемы DevOps для машинного обучения.

В 2022 году появилась оркестровка контейнеров. Сам Kubernetes появился ещё в 2022 году (первый релиз), а в 2022 году появился Microsoft Azure Kubernetes Service (AKS), и также другие облачные сервисы выпустили управляемые службы оркестраторов контейнеров для облачных приложений.

В 2022 году GitHub вырос и стал еще более значимым для сообщества. Если в 2009 на GitHub было 50 тысяч программистов, то в 2022 их стало уже 40 миллионов. На данный момент мы перевалили за 50 миллионов. Более 50 миллионов программистов, а также людей с другими бэкграундами, которые имеют репозитории или аккаунт на GitHub, сотрудничают над опенсорс-проектами, и многие из них активно работают над всеми этими программами.

Также в 2022 году GitHub выпустил компонент Actions для CI/CD и автоматизированной безопасности, о которой можно говорить очень долго.  Теперь мы вносим вклад не только в опенсорс-код, но и в остальные практики DevOps — разработку и эксплуатацию.

Создавайте для отказоустойчивости

Мы говорили о том, что выпускали ПО на DVD, а потом клиенты устанавливали и управляли серверами. И нам нужно было научиться, как запускать приложения в продакшн, то есть как справляться с инцидентами, поддерживать SLA и т. д.

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

Наша дорога к DevOps  продолжается, и сейчас, например, мы учимся удалённой работе. И сделать это нужно было очень быстро — перевести 150 тысяч сотрудников в марте 2022-го. Как сказал Сатья Наделла, нужно было очень быстро научиться тому, как работать удалённо и пройти двухлетнюю цифровую трансформацию за два месяца. Об этом тоже можно говорить очень долго.

Ещё мы работаем, например, над разработкой MLOps — практик машинного обучения, которые включают в себя DevOps. Microsoft работает над тем, чтобы поставить в облако Azure машинное обучение и иметь возможность добавить элементы пайплайна CI/CD в МО.

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

Путь из тысячи километров начинается с одного спринта. DevOps — это не магия.

Спасибо большое за внимание! Больше информации по теме есть на странице The DevOps journey at Microsoft.

Сейчас Саша работает уже не в GitHub, а в Red Hat. Но по-прежнему выступает у нас на DevOops: в ноябре снова проведём конференцию, и там она представит доклад «SRE, Managed Services and the path to the future».

А помимо этого, там будет и много других докладов: и про конкретные инструменты (Kubernetes, Helm, GitHub Actions), и про общие подходы.

В общем, если тема DevOps интересна вам не только в отношении «что делают в Microsoft», но и в отношении «что делать нам», то на DevOops 2021 вам будет интересно. Конференция пройдёт 8–11 ноября в онлайне, более подробная информация и билеты — на сайте.

Создавайте ясность

Итак, как мы создаём ясность? Какое-то время назад вышла книга Джона Дорра «Измеряйте самое важное» (МИФ, 2022). В книге описывается система OKR, которая пришла из Intel (изначально она называлась MBOs), потом была перенята и модифицирована Google и теперь есть и в Microsoft. OKR (Objectives and Key Results) — это цели и ключевые результаты.

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

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

Ключевые результаты подразделяются на фиксированные и желательные. Фиксированные — это то, что надо достичь на 100%. Не факт, что мы достигнем результата на 100%, но мы хотим, чтобы он все время приближался к этому показателю. Желательные (aspirational) — это некие амбициозные цели, которые мы не до конца можем достигнуть, но хотим к этому стремиться.

Это не единственная система, которой можно пользоваться, но в OKR есть кое-что очень полезное. Например, мы говорим о том, чего хотим добиться в конце, а также фокусируемся на всей организации, и всё очень наглядно. Мы начинаем с того, что создаем OKR для продукта, а потом спускаемся ниже на уровень отдельных сервисов в продукте и создаём OKR для них.

Затем это идет в каждую отдельную команду, при желании и возможности OKR можно прописать для каждого члена команды. Уровни этой лесенки должны сочетаться: если ваши командные цели будут достигнуты, то и цели продукта тоже, и тогда она будет иметь смысл.

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

Необходимо измерять то, что вам важно. Например, в Azure DevOps мы измеряем использование, то есть привлечение клиентов: сколько клиентов к нам присоединяется, сколько пользуется продуктом, насколько они удовлетворены им. По сути, это всем известный NPS (Net Promoter Score — индекс определения приверженности потребителей товару).

Также измеряется отток (churn) — сколько людей присоединяется и потом сразу уходит. Потом — эффективность, то есть сколько времени занимает компиляция, тестирование, развёртывание во все среды, а также Live Site Health — сколько времени занимает выявление и исправление инцидентов; также работа над SLA, например, SLA на определенного клиента, потому что иногда бывают баги, которые касаются только одного клиента, и на это тоже нужно смотреть, а не только на то, что влияет на всех.

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

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