Какие типичные признаки и сигналы команды DevOps недоукомплектованы? Как бы вы обосновали / объяснили запрос на новое добавление в команду?

Я хотел бы, чтобы вопрос оставался общим, но вот дополнительная информация:

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

Есть четыре основные причины, почему вы чувствуете, что ваша команда недоукомплектована:

1. Плохая организация и планирование работы
2. Делать работу должен кто-то другой
3. Делать работу, которую не следует делать вообще
4. Быть фактически недоукомплектованным

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

Далее рассмотрим четыре вида работ, упомянутых в проекте Феникс:

1. Бизнес-проекты - что вы делаете для других команд в организации
2. Внутренние проекты - что вы делаете, чтобы облегчить вашу работу в будущем
3. Плановое техническое обслуживание - что вы делаете, чтобы держать свет
4. Незапланированные прерывания - что вы делаете, потому что что-то пошло не так

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

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

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

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

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

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

Оцените свои процессы и посмотрите, насколько они соответствуют общепринятым принципам DevOps и насколько хорошо вы следуете передовым отраслевым практикам.

Я предполагаю, что эта команда из двух человек переходит от проекта к проекту и создает там вещи DevOps (создание конвейеров CI / CD, поддержка других разработчиков, создающих файлы Docker, или любую другую технологию, которую вы используете). Другими словами, введите 3, 4, 5 или 6 согласно http://web.devopstopologies.com/ .

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

Еще один признак изменения чего-либо - это если вы внимательно присмотритесь и заметите, что создаете «бункер DevOps», в котором все ноу-хау DevOps сосредоточено в этих двух парнях / девчонках, а все остальные просто откидываются, потому что эти двое "делают DevOps". Дело не в DevOps. Если это так, подумайте о культурном аспекте и измените их, чтобы они стали больше евангелистами / учителями / тренерами для других команд.

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

У меня сложилось впечатление, что DevSecOps - это образ мышления, а не команда - если у вас есть «команда» Dev (Sec) Ops, вы делаете это неправильно ... Я пытаюсь обернуть голову, нанося двух «инженеров DevOps» вместе и называя их «Команда DevOps».

У нас есть команды разработчиков, SCM, Application Security и системные инженеры, которые работают в тандеме для быстрой модели развертывания / выпуска, чтобы продвигать изменения кода и конфигурации / системы до заданной конечной точки - либо подготовки, либо производства.

Это не имеет ничего общего с любыми инженерами devOps как таковыми.

Группировка задач

Подход, который мы использовали в прошлом в аналогичных ситуациях, состоит в том, чтобы организовать работу команды по 4 основным группам задач и выделить эквивалент 2 FTE (эквиваленты полной занятости) для (попытки) выполнения этих задач. В нашем случае это было связано с работой службы поддержки SCM в среде мэйнфреймов, где около 300 разработчиков запрашивали всевозможную помощь / вмешательство у этих двух FTE. Группы задач организованы в 4 возможных приоритетов:

• Задачи с приоритетом 1 и 2 должны быть выполнены (оправдания / переговоры невозможны)
• Задачи Приоритета 3 должны быть выполнены « как только позволит время».
• Задачи с приоритетом 4 должны быть выполнены « если позволяет время».

Читайте дальше для получения более подробной информации о типе задач в каждой из этих 4 групп ...

Описание задач

Приоритет 1 - работа службы поддержки

• Эксперты, которые легко доступны и всегда доступны.
• По телефону, электронной почте или билетной системе в рабочее время.
• Соответствует предопределенным соглашениям об уровне обслуживания.
• ITIL-регистрация всех звонков в службу поддержки с периодическим сообщением обо всех звонках.
• Применяйте экстренные настройки (обходные пути) для критических проблем.

Приоритет 2 - Дежурная служба

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

Приоритет 3 - текущее обслуживание

• Администрация.
• Заявка на посадку.
• Уборка номера.
• Улучшения производительности.
• Космическое управление.
• Настройка потребления ресурсов.
• Предложите усовершенствования для настройки, чтобы уменьшить количество обращений в службу поддержки и / или наблюдать за дежурными вмешательствами.

Приоритет 4 - Исправления и улучшения

• Создание и поддержка пользовательской документации.
• QA тестирование новых настроек.
• Разработка и внедрение запросов на улучшение.
• Участвуйте в DRP-тестировании.

оценка

Если вы используете подход, описанный выше, могут произойти (будут!) Разные вещи:

• Если команда недоукомплектована, вероятно, большую часть времени уйдет на задачи с приоритетом 1 и 2, в то время как на выполнение задач с приоритетом 3 может потребоваться некоторое время ... и задачи с приоритетом 4 могут испытывать голод (кажется, что времени для эти задачи).
• Чем больше (становится) времени, доступного для « инвестирования » в задачи с приоритетом 4, тем больше времени, необходимого для задач с приоритетом 1 и 2, будет сокращено, так что можно будет «инвестировать» еще больше времени (из доступного бюджета в 2 FTE) «в приоритете 4 задачи.
• Вы будете поражены, увидев, как через некоторое время количество задач с приоритетом 1 и 2 уменьшится. И если вы делаете адекватные отчеты об этих задачах, это то, что руководство любит слышать. В нашем случае это число снизилось с примерно 300 в месяц до менее 100 в месяц ...
• Однако если у 2-х FTE, кажется, никогда (или вряд ли) есть время для выполнения приоритетных задач 4, то у вас есть прекрасное объяснение и доказательство для вашего руководства ... что вы недоукомплектованы.