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

Что такое DevOps?

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

Итак, вы можете спросить: Что, черт возьми, такое DevOps?. DevOps — это методология, используемая в разработке программного обеспечения и ИТ-индустрии. В целом, это набор методов, которые объединяют и автоматизируют повседневную работу разработчиков (Dev) и ИТ-операций (Ops) для улучшения и сокращения жизненного цикла разработки системы.

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

  • Бережливые операции
  • Технологический поток создания ценности
  • Принципы непрерывного обучения и экспериментирования
  • Как эта теория помогла мне как разработчику и Nmbrs

DevOps следует принципам бережливого производства

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

Философия бережливого производства основана на следующих принципах:

  1. Устранение отходов
  2. Качество сборки в
  3. Создавайте знания
  4. Отложить обязательство
  5. Доставить быстро
  6. Уважайте людей
  7. Оптимизировать все

Когда вы думаете о DevOps, вы можете думать о нем как о принципе бережливого производства.

Технологический поток создания ценности

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

В своей книге Карта потока создания ценности Майк Остерлинг и Карен Мартин определяют поток создания ценности как последовательность действий, которые организация обязуется выполнить по запросу клиента или последовательность действий, необходимых для разработки, производства и поставки товара. или услуги клиенту, включая двойные потоки информации и материала».

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

  1. Время выполнения
  2. Время обработки
  3. Процент завершения и точности (%C/A)

Время выполнения против времени обработки

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

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

Процент завершения и точности

Помимо времени выполнения заказа и процесса, третьим ключевым показателем в технологическом потоке создания ценности является процент завершения и точности (%C/A). Этот показатель отражает качество вывода каждого процесса. Чтобы измерить его, вам нужно спросить нижестоящих потребителей, сколько времени они получают работу, которая «пригодна для использования как есть», без необходимости исправлять ее или обращаться в службу поддержки. Если ничего переделывать не нужно, то %C/A равно 100%. Если вам нужно исправить несколько ошибок, то процент будет ниже. Например, если вам нужно переработать 25% всего, то %C/A составит 75%.

Чем ниже процент, тем больше придется переделывать. Даже небольшое изменение влияет на всю команду разработчиков и дорожную карту компании. Высокий %C/A означает, что весь процесс проходит гладко для клиента, заинтересованных сторон, владельца продукта и команды разработчиков.

Теперь вы, должно быть, задаетесь вопросом: возможно ли улучшить поток создания ценности? Если да, то как?

Как улучшить технологический поток создания ценности

Сократите время выполнения заказа

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

Ограничить количество незавершенных работ (WIP)

Слишком большое количество незавершенных работ может привести к задержке обработки, поскольку разработчики работают над несколькими задачами одновременно. Если каждый разработчик работает одновременно только над одной задачей, будет проще выявить возможные проблемы, мешающие завершению работы. У вас также будет больше прозрачности в отношении того, что делается, если у вас есть только одна выполняемая задача, назначенная одному человеку. Agile/Scrum Master должен отслеживать объем работы, которая находится в процессе. Если у вас его нет, это должна быть роль менеджера проекта.

Уменьшите размер партии

Разница между большими и малыми размерами партий огромна (см. рисунок ниже). Предположим, что каждая из четырех операций занимает десять секунд для каждого из десяти конвертов. При использовании стратегии большего размера партии первый заполненный и проштампованный конверт изготавливается только через 160 секунд. В то время как с самой маленькой партией, это 40 секунд. Это сокращение времени на 75%.

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

Сокращение брака и переделки

Другими словами, уменьшите количество незавершенной работы, которую вам нужно сделать снова. Команда должна обеспечивать более высокое качество своих циклов разработки (в Nmbrs мы работаем со спринтами), исправляя проблемы по мере их возникновения. Например, вы можете использовать Sprint Reviews, чтобы получать отзывы от стейкхолдеров и клиентов, и если им что-то не нравится, сразу меняйте это. Кроме того, разработчикам следует более тесно сотрудничать с службой обеспечения качества. После завершения задачи попросите отдел обеспечения качества протестировать ее. Это не должен быть разработчик, который проделал работу, чтобы продолжить тест.

Как мне помогла теория DevOps

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

Заключение

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

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

Ресурсы

  1. Руководство по DevOps, Джин Ким, Джез Хамбл, Патрик Дебуа, Джон Уилис
  2. Карта потока создания ценности, Карен Мартин, Майк Остерлинг
  3. Бережливая разработка программного обеспечения: Agile Toolkit, Мэри и Том Поппендик
  4. https://aws.amazon.com/devops/what-is-devops/
  5. https://www.atlassian.com/software/confluence