Как ITIL, DevOps и SRE работают вместе в вашей организации

Опубликовано: 2020-03-02

Когда кто-то спрашивает, к какому типу относится ваша организация, можете ли вы уверенно ответить, что это ITIL, DevOps или SRE?

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

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

Что такое ИТИЛ? Если вы не знакомы…

ITIL расшифровывается как библиотека инфраструктуры информационных технологий и представляет собой методологию, разработанную для создания единого источника передового опыта в области информационных технологий. По словам Сары К. Уайт и Линн Грейнер:

«Разработанный Центральным агентством по компьютерам и телекоммуникациям (CCTA) британского правительства в 1980-х годах, ITIL сначала состоял из более чем 30 книг, разработанных и выпущенных с течением времени, которые кодифицировали передовой опыт в области информационных технологий, собранный из многих источников (включая лучшие поставщики). практики) по всему миру».

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

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

Какая связь между ITIL и ITSM?

ITSM, или управление безопасностью информационных технологий, представляет собой процесс управления компанией своими ИТ-услугами. Этот процесс очень ориентирован на клиента и обычно состоит из 5 шагов:

  1. Стратегия обслуживания
  2. Сервисный дизайн
  3. Переход на сервис
  4. Сервисная операция
  5. Постоянное улучшение обслуживания

ITIL — это фреймворк для реализации практик ITSM. Эта структура не зависит от организации и, следовательно, может применяться практически ко всем предприятиям, даже если ИТ-отдел занимается только внутренними клиентами. Поскольку они так тесно связаны, неудивительно, что ITIL и ITSM совпадают по многим вопросам.

Согласно itiltraining.com:

«Большое внимание уделяется постоянному совершенствованию. Это включает в себя постоянное измерение и улучшение процессов, ИТ-услуг и ИТ-инфраструктуры. Это максимизирует их эффективность, результативность и рентабельность».

Как ITIL работает с DevOps

Следуя процессу ITIL, вы фокусируетесь на согласовании ИТ с бизнес-целями вашей организации. Это хорошо согласуется с философией DevOps, заключающейся в разрушении разрозненности во всей организации. Кроме того, разбивая эти разрозненные структуры, вы можете устранить узкие места в общении, позволяя командам быстрее предоставлять функции, которые нужны клиентам, и более точно соблюдать модель CAMS (культура, автоматизация, измерение, совместное использование). Но как это на самом деле выглядит применительно к организации?

Когда какой использовать?

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

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

График ITIL и DevOps

Согласование между ИТ и остальной частью вашей организации

Результатом использования сочетания лучших практик ITIL и DevOps является лучшее согласование с целями всей организации. Когда ИТ и остальная часть организации функционируют как полностью независимые подразделения, одна сторона, скорее всего, всегда будет чувствовать себя перегруженной работой и недостаточной поддержкой. В «Проекте Феникс», романе, повествующем о борьбе вымышленной организации с ИТ-интеграцией, этот конфликт становится центральным.

В книге ИТ-отдел частично отвечал за успешные инициативы в области исследований и разработок и продаж. НИОКР требовались точные данные и отчетность по запасам, чтобы пополнять запасы и своевременно выводить на рынок новые продукты. Для продаж требовались эффективные CRM, телефонная/голосовая почта и MRP-система. В противном случае у них не было возможности добавлять или изменять заказы клиентов и не было возможности управлять состоянием клиентов.

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

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

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

Лучшие практики ITIL и DevOps

Совместное владение и постоянное совершенствование

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

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

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

Как ITIL работает с SRE

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

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

Семь принципов ITIL 4

Ниже приведены семь принципов ITIL 4. Давайте обсудим их более подробно.

1. Начните с того, где вы находитесь

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

2. Сохраняйте простоту и практичность

В главе о простоте книги Google SRE говорится:

«В отличие от почти всего остального в жизни, «скучность» на самом деле является положительным качеством, когда речь идет о программном обеспечении! Мы не хотим, чтобы наши программы были спонтанными и интересными; мы хотим, чтобы они придерживались сценария и предсказуемо достигали своих бизнес-целей».

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

3. Оптимизируйте и автоматизируйте

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

4. Итеративно продвигайтесь вперед с обратной связью

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

5. Сотрудничайте и повышайте узнаваемость

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

6. Сосредоточьтесь на ценности

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

7. Думайте и работайте комплексно

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

Гибкое и быстрое управление изменениями

Одна из лучших практик ITIL — скоординированное управление изменениями под контролем совета по авторизации изменений (CAB). Однако, как отмечает партнер Mindbridge Каймар Кару:

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

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

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

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

Команда мечты ITIL, DevOps и SRE

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

ИТИЛ DevOps СРЭ
Философия и культура

Согласуйте ИТ с потребностями бизнеса, чтобы создать симбиотические отношения

Командно-административное управление и управление процессами для снижения рисков

Улучшите командную работу и устраните разрозненность

Направлена ​​на создание согласованности и минимизацию разрозненности между разработкой и эксплуатацией.

Часто ориентирован на помощь командам в повышении скорости и качества развертывания.

Избавьтесь от тяжелого труда, дизайн для удобства

Рассматривает операции как программную проблему, чтобы максимизировать эффективность

Идеально подходит для поддержки распределенных сервисов в масштабе, которые должны быть сверхнадежными

Ключевые практики и инструменты

Планирование мощности

Каталог услуг/CMDB

Управление проблемами

Управление изменениями / консультативный совет

Планирование мощности

По вызову

Микросервисы

CI/CD

Инфра как код

Мониторинг и регистрация

Общение и сотрудничество

Соответствие ключевым практикам DevOps наряду с: прогрессивными развертываниями, SLO и бюджетами ошибок.

Наблюдаемость

Хаос-инженерия

Командная работа Традиционная модель централизованного процесса и видимости. Работа обычно ставится в очередь («водопад»).
Инциденты переданы через центральную группу NOC

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

Как правило, это означает, что разработчики дежурят над тем, что они создают, но могут привлекать операторов для поддержки L2.

SRE часто выступают в качестве консультантов для установления практики, ориентированной на надежность.


Роли инженеров-программистов и SRE сходятся, согласовывая общие процессы и результаты

Ключевые меры Доступность, # инцидентов, # эскалаций и т. д. Доступность, частота развертывания и т. д.

SLO, а также доступность, частота развертывания и т. д.

Бюджеты ошибок

Вывод

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

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