ITSM для высокоскоростных команд
Как организовать ИТ-поддержку с помощью 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 для работы с репозиторием кода.
Отчасти эти инструменты работают хорошо, потому что они хорошо работают вместе. Если вы уходите от разобщенности в структурах команд, вам захочется того же при выборе инструментов.
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
Читать технический документAtlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Читать технический документ