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

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

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

В статье я поделюсь опытом, как подойти к этой проблеме системно: внедрить DevOps as a Service так, чтобы он стал не «еще одной модной практикой», а реально работающим сервисом внутри enterprise. Разберем, какие сложности чаще всего встречаются на пути, какие метрики помогают понять, что вы движетесь правильно, и как справляться с сопротивлением команд.

Всем доброе утро!
На связи вновь Крылов Александр и сегодня я решил поделиться мыслями по тому, как можно применить опыт DevOps Governance в Enterprice, который я ранее описывал в в этой статье. Прошло время и опыт был переиспользован для разработки продукта на примере компании Bimeister. А началось это аж в августе 2023 года.

Что тут важно сказать - нет, это не будет детальной расшифровкой с уточнениями доклада с DevOops 2023, с которым так же можно будет ознакомиться по ссылке выше. В данной статье я расскажу ряд аспектов отличия Governance в Enterprice и то, как он может выглядеть в компании разработчике своего продукта. Помимо этого, я так же расскажу, какие работы удалось провести за год в компании, а какие нет.

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть 1, Часть 2, Часть 3, Часть 4, Часть 5. Сегодня мы обсудим создание площадки обучения DevOps в стенах компании для обмена опытом между коллегами разных подразделений, повышения компетенции и культуры обучения.

Итак, проблема, которую мы будем решать — это смещение фокуса с развития на поддержку.

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем. В прошлых статьях мы описали сам подход, показали пути решения различных проблем. Со статьями можно ознакомиться здесь Часть1, Часть2, Часть 3. Сегодня мы поговорим о построении процесса развития сотрудников и команды в целом, а также о процессе управления инициативами.

Прежде всего, нам стоит понять сильные и слабые стороны каждого сотрудника подразделения. Начнём мы, безусловно, с hard skills, но и про софтскилы не будем забывать.

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service. В прошлых статьях мы описали подход и показали пути решения проблем с контролем ресурсов команды и инфраструктуры, с ними можно ознакомиться тут и тут. Сегодня мы поговорим о построении процесса взаимодействия команд разработки и тестирования со службой DevOps, при этом отходя от дежурств подразделения в чате.

Для начала попробую описать суть проблемы. Представим, что у нас есть небольшое подразделение, не более 5 человек, которое как служба - одна на все команды разработки и тестирования. Количество обращающихся команд может быть от 10 до 20. Казалось бы – не мало ли людей на такое количество команд? Да, не много. А не хотим ли мы увеличить состав? Но реальность такова, что проблему обращений надо решить с помощью имеющихся в наличии ресурсов, а потом, разобравшись с ней и построив процесс работы с бэклогом команды и пониманием его объёма, уже запрашивать ресурсы на расширение команды. Пока этого нет, можем рассчитывать только на имеющиеся руки.

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

Первая проблема, с которой мы начнём - это тушение пожара в инфраструктуре.

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

Вопросы и аудитория

Прежде чем начинать рассказ, следует ответить на вопрос, чем внедрение “DevOps as service” может быть полезно для компании? Какую пользу это внедрение может принести? И что так же не маловажно – кому это будет полезно?

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

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

Всем доброе утро!
Сегодня мы поднимем такую интересную тему, как DevOps Governance в Enterprise.

В современных реалиях не так просто прийти к бизнесу и сказать: "Давайте всё автоматизируем, и всё будет хорошо!" Нет, это так не работает, особенно в крупных компаниях. А если у Вас ещё и нет единого процесса внесения изменений, то каждый будет кто в лес по грибы, кто домой за скатертью-самобранкой приходить и навязывать свои идеи.

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

Я расскажу Вам о том, как мы внедряли матрицу зрелости, сколько внедряли и к каким результатам это привело за несколько лет. Мы с Вами пройдём путь от появления идеи до получения осязаемых результатов, с учётом трудностей внедрения и появления побочных процессов, вроде базовых требований на старте проектов при работе с вендорами.