Які типові знаки та сигнали команди DevOps не мають достатньої кількості? Як би ви обґрунтували / пояснили запит на нове доповнення до команди?

Я хотів би тримати питання загальним, але ось додаткова інформація:

На даний момент у нас працює 2 фахівці DevOps як команда, але запити та кількість та складність продукції зростають. Ми думаємо просити нове доповнення до команди, але маємо певні труднощі з поясненням і доведенням, чому це було б хорошою ідеєю.

Існує чотири основні причини, через які ви можете відчути, що ваша команда не має достатнього рівня:

1. Погана організація та планування роботи
2. Робити роботу має хтось інший
3. Робити роботу, яку взагалі не слід робити
4. Будучи фактично недостатньою

Почніть з огляду перших трьох пунктів. Прочитайте проект Phoenix про ідеї, як зробити перше. Поцікавтеся кожним завданням, яким ви допомагаєте будь-кому, якщо це взагалі має бути виконано, і якщо саме ви повинні виконувати завдання, або якщо ви просто повинні дозволити тому, хто це потребує, зробити це самостійно. Це дасть вам деяку документацію щодо того, чому потрібна вся робота, яку ви виконуєте.

Далі розгляньте чотири види робіт, згадані в проекті Phoenix:

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

Якщо робота вашої команди є стійкою, ви витратите приблизно стільки ж часу на кожну з чотирьох. Якщо незаплановані роботи починають наповзати майже до 50% вашого часу, це знак, що ви точно не маєте достатнього рівня.

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

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

Відповідь : Як тільки ви помітили, що ви не обходитесь чи не відкладаєте безліч завдань, особливо технічного обслуговування, я думаю, що це хороший показник (з того, що я відчував). Крім того, чим більше нових проектів і команд розробників, які тим менше, чим розповсюджується команда DevOps, тим більше людей вам знадобиться.

Супер легко просто потрапляти в день у день виконання завдань, але я вважаю, що це дуже важливо (навіть раз на місяць) зробити крок назад і оцінити це.

Насправді я беру сторінку з підручника SRE про цю, що я вважаю дуже актуальною. Спеціальність DevOps не передбачає горизонтального зростання організації. Скоріше, якщо ви бачите, що щось не робиться, то це сигнал, що ви не належним чином надаєте розробникам можливість самостійного обслуговування.

Оцініть свої процеси і подивіться, як вони узгоджуються з загальноприйнятими принципами DevOps та наскільки добре ви дотримуєтесь найкращих практик галузі.

Я припускаю, що ця команда із двох людей переходить від проекту до проекту та встановлює там матеріали DevOps (створюючи CI / CD конвеєри, підтримуючи інші розробники, створюючи Dockerfiles, або будь-яку технологію, яку ви використовуєте). Іншими словами, введіть 3, 4, 5 або 6 відповідно до http://web.devopstopologies.com/ .

У цьому випадку ознакою нестачі є просто занадто велика навантаження для цих двох; занадто багато проектів, що вимагають їх послуг; занадто багато квитків; через деякий час; стрес, вигорання. Ці фактори повинні бути достатніми причинами, щоб відповідальне керівництво додало більше можливостей. Я не бачу в цьому специфічного знаку DevOps, це лише функція, що не має достатнього рівня.

Ще один знак, щоб щось змінити - це якщо ви добре поглянете і якщо ви помітили, що ви створюєте "силос DevOps", в якому всі ноу-хау DevOps сконцентровані в цих двох хлопців / дівчат, а всі інші просто відхиляються, тому що ці двоє "роблять DevOps". Це не сенс DevOps. Якщо це так, подумайте про культурний аспект і модифікуйте їх, щоб вони були більш євангелістами / вчителями / тренерами для інших команд.

В обох випадках, більш глибокій причині того, що мати DevOps на першому місці, є хороша річ (загальна Good Stuff) має бути зрозумілою для вищого керівництва. Якщо ви не можете перенести це повідомлення поперек, зменшіть роботу, яку виконує ваша команда, перемістивши її на звичайні програми Devs / Ops (як це має бути в будь-якому випадку).

Я був під враженням, що DevSecOps був менталітетом, а не командою. Якщо у вас є команда Dev (Sec) Ops, ви робите це неправильно ... Я намагаюся обернути голову, поставивши двох "DevOps Engineers" разом і називаючи їх "командою DevOps".

У нас є команди розробників, SCM, інженерів з безпеки прикладних програм та всіх систем, які працюють в тандемі для швидкого розгортання / випуску моделі для виштовхування коду та конфігурації / змін системи до заданої кінцевої точки - або постановки, або виробництва

Це не має нічого спільного з жодними інженерами "devOps", як такими.

Групування завдань

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

• Завдання Пріоритету 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 ДВТ, здається, ніколи (або навряд чи) мають час для пріоритетних 4 завдань, то у вас є ідеальне пояснення та доказ для вашого управління ... що ви не маєте достатнього рівня.