Как организовать ИТ-поддержку с помощью DevOps

Доказано, что внедрение принципов DevOps в командах ИТ-обслуживания и инженерных командах значительно улучшает качество обслуживания клиентов и решения проблем, укрепляет командный дух и повышает эффективность бизнеса. И действительно, компании, реализовавшие принципы DevOps, сообщают, что в среднем удовлетворенность их клиентов повысилась на 45 %, а продуктивность сотрудников — на 43 %. При этом частота появления дефектов снизилась на 41 %, а затраты на ИТ — на 38 %.

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

Что такое DevOps?

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

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

Почему следует использовать DevOps для ИТ-поддержки?

Если судить с точки зрения бизнеса, цифры говорят сами за себя: рост удовлетворенности клиентов на 45 %, повышение продуктивности сотрудников на 43 %, а также снижение затрат на ИТ на 38 %. В конечном итоге движение DevOps значительно помогло бизнесу. Вероятно, по этой причине 4 из 5 компаний утверждают, что используют как минимум некоторые принципы DevOps.

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

Раньше эксплуатационные команды испытывали раздражение при виде новых релизов, о которых ничего не знали и которые не были готовы поддерживать (по мнению Gartner, в этом причина 85–87 % инцидентов). Концепция DevOps открывает линии связи и готовит эксплуатационные ИТ-команды к предстоящим событиям. До появления концепции команды разработчиков расстраивались при возврате релизов эксплуатационной командой, из-за чего откладывался запуск. Теперь обе команды могут работать вместе, чтобы ускорить запуск релизов без вреда для обещаний по соглашениям SLA и целей SLO.

DevOps для ИТ-услуг: рекомендации

Уделяйте первоочередное внимание изменению культуры

Самой большой проблемой при интеграции DevOps является изменение культуры. 

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

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

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

Используйте автоматизацию везде, где возможно

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

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

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

• Рабочий процесс (например, ускорение прохождения заявок через службу поддержки)

• Знания (при возникновении инцидента инструмент управления услугами должен автоматически ссылаться на соответствующие знания и документацию)

• Эскалация (если проблему могут решить только два человека в организации, интеллектуальная система должна эскалировать ее непосредственно им, а не следовать жестким линейным маршрутам эскалации)

Отслеживайте важные показатели

Поскольку команда разработки и ИТ-команда эксплуатации работают вместе, они должны отслеживать состояние систем. 

К основным ключевым показателям эффективности DevOps (KPI) относятся: MTBF (среднее время между отказами), MTTR (среднее время восстановления, устранения, отклика или решения проблемы), MTTF (средняя наработка на отказ) и MTTA (среднее время подтверждения). Кроме того, многие компании опираются на такие числовые показатели, как количество оповещений или запросов, сгенерированных за определенный промежуток времени, стоимость одной минуты простоя и стоимость запроса/обращения в службу поддержки. 

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

Делайте акцент на общем доступе

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

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

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

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

ITIL и DevOps

Если вы следуете методике ITIL, вам может быть интересно, как туда вписывается концепция DevOps. Для многих компаний принципы ITIL и DevOps могут работать вместе. И действительно, мы в Atlassian знаем много компаний, которые используют положительные стороны и достоинства обоих подходов.

Прочтите эту цитату о сравнении DevOps и ITIL: «Нам нужно и то, и другое. Это не конкуренция, а комплиментарность. Мы должны работать быстрее и эффективнее, но этого не будет без процессов и управления. Современные высокопроизводительные команды и организации начинают это осознавать и пользуются элементами обоих подходов, выходя за рамки ультимативного требования "или-или"».

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

Инструменты для организаций, ориентированных на DevOps

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

При оценке новых инструментов важно задавать вопросы вроде приведенных ниже.

• Работает ли этот инструмент в нашей среде и интегрируется ли с существующими инструментами?

• Соответствует ли он нашим потребностям?

• Могут ли все новые инструменты работать вместе, как единый набор? 

Мы в Atlassian не претендуем на объективность, однако наши сотрудники используют Jira Service Management для управления ИТ-услугами, Jira Software для разработки программного обеспечения и Bitbucket для работы с репозиторием кода.

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