DevOps с точки зрения Теории ограничений

DevOps с точки зрения Теории ограничений

Частое употребления модного словечка «DevOps» (development + operations = devops), вероятно, не приведет ни к каким заметным улучшениям в организации. Для достижения существенных результатов необходимо принятие и понимание необходимости новых политик, и в то же время принудительный отказ от прежних способов работы.

Какие именно новые политики и практики необходимо принять? В этой статье мы попытаемся охватить некоторые наиболее важные пункты.

Дерево цели для DevOps

Рис. 1. Дерево цели для DevOps

На картинке выше показаны Критически важные факторы успеха и Необходимые условия, чтобы создать Прекрасные ИТ-системы, которые, как мы предполагаем, приводят к отличной конкурентоспособности на рынке. Изображение в заголовке – это «Дерево целей», пример логики Мыслительных процессов, которые являются частью свода знаний Теории ограничений.

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

После того, как программное обеспечение разработано и поставлено, оно должно работать надежно, чтобы клиенты могли спокойно его использовать. Таким образом, здесь возникает конфликт. С одной стороны, необходимо делать частые изменения и улучшения, с другой стороны, обеспечивать постоянную стабильность, надежность и безопасность. Традиционно организации решали эту проблему, назначая двух (или более) разных менеджеров в своей организации для выполнения этих задач. Вице-президент по НИОКР управляет разработчиками, часто вынужденными делать изменениях, и вице-президент по обслуживания (или по IT) управляет системными администраторами, которые не любят делать никаких изменений, которые могут дестабилизировать системы.

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

Внедрение DevOps путем найма третьего менеджера (или вице-президента) часто может сделать проблему еще хуже и никоим образом не приближает к цели более быстрой и качественной поставки ИТ-услуг. Теперь у компании уже не два, а три менеджера, конфликтующих друг с другом.

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

Виктор Вальчук
Критическая цепь. Управление проектами по ТОС

Цель любого проекта: «Завершить проект в срок, в полном объеме и в рамках выделенного бюджета». Для этого необходима методика, умеющая справляться с возникающей неопределенностью. Метод Критической цепи позволяет эффективно управлять неопределенностью. Использование буфера проекта позволяет вовремя получать информацию о задачах, которые ведут к опозданию проекта и ставят под угрозу его бюджет.

Тренеры: В.В. Вальчук, В.Е. Краснов. Старт: 3 июня 2024.

ПОДРОБНЕЕ

Быстрая поставка

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

Структура процесса поставки

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

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

Частота поставки

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

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

Автоматизация поставки

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

Прекратите поставку один раз в две недели, выпускайте релизы каждый день, и это сделает вас в три раза быстрее. Согласно отчету «State of DevOps 2017» высокопроизводительные организации в 4 раза быстрее, чем их конкуренты.

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

Надежные и безопасные системы

Лозунг «Двигаться быстро и обеспечить прорыв» уже не устраивает Facebook, который отошел от своей оригинальной мантры и принял очень важное изменение: «Двигаться быстро со стабильным результатом».

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

Для обеспечения надежности ИТ-систем необходимы следующие условия:

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

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

Вывод

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

Таблица 1

Неконкурентные IT-системы Отличные IT-системы
Ручной процесс поставки Автоматизированный поток поставок
Релиз 1 раз в полгода (в лучшем случае) Несколько релизов ежедневно
Срок поставки от идеи до релиза > 1 года Срок поставки от идеи до релиза < 1 недели
Время на восстановление > 1 дня Время на восстановление < 30 минут
Невозможно установить ПО множеству клиентов сразу Возможно установить ПО неограниченному количеству клиентов сразу
Количество отказов при развертывании 80% Количество отказов при развертывании < 1 в год
Отсутствует обнаружение ошибок в системе, приложениях или в безопасности Моментальное предупреждение о ненормальном поведении или потенциальной угрозе
Постепенное увеличение затрат и уменьшение скорости работы в существующей и новой версии Постоянное улучшение скорости работы системы и снижение затрат на основе анализа данных
Плохие методы доступа (единый одноуровневый пароль для всех) Маломодульный контроль доступа в систему
Нет аудитов безопасности Ежемесячный аудит и отчет по безопасности

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

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

Автор: Evgeny Zislis
Источник

Прорыв

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!


Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.

Речкалов

Редактор сайта TOCPEOPLE.COM. Переводчик материалов по Теории ограничений
Организации: «АРБ-Консалтинг», Академия Теории ограничений
Звоните: +7 (351) 245-03-03
Пишите: info@tocpeople.com

Давайте обсудим...