Кожен програміст повинен знати, що таке DevOps

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

Список CD/DVD-дисків

** Pipeline ** — автоматизована послідовність кроків, які перетворюють початковий код на розгорнуту, запущену службу. Типовий конвеєр включає етапи збирання, тестування і розгортання. « Конвейер зазнав невдачі на етапі тестування інтеграції. »

** Artefact ** — вивід кроку збирання, наприклад, зкомпільований бінарний файл, штамп Docker або файл JAR. Артефакти версуються і зберігаються у реєстрі артефактів. « Завдання розгортання витягує артефакт з реєстру і відсилає його до кластера. »

** Шлюз розгортання ** — крок перевірки або затвердження, який слід виконати перед тим, як конвеєр перейде до наступного середовища. Шлюзи можуть бути автоматизованими (поріг тестування) або ручними (затвердження змін). « У нас є шлюз розгортання, який вимагає підписання старшим інженером перед випуском у виробництво. »

** Відновлення ** — повернення розгорнутої версії до попереднього стану, який вважається належним. Відрізняється від перенесення вперед, коли ви виправляєте перенесення уперед за допомогою розгортання виправленої версії. « Коли кількість помилок збільшилася, інженер, який перебував на зв’ язку, запустив відновлення упродовж трьох хвилин. »

** Розгортання синьо- зеленого кольору ** — стратегія випуску, яка запускає два ідентичні виробничі середовища (синє і зелене); переключення трафіку зі старої версії на нову без перерви. « Розгортання синьо- зеленого кольору дозволяє нам випускати без вікна обслуговування »

** Canary release ** — поступове перенаправлення невеликого відсотка трафіку до нової версії, щоб виявити проблеми перед повним випуском. « Ми запустили 5% Canary на 30 хвилин, перш ніж підвищити його до 100% »

Інфраструктурний словник

** Обслуговування** — процес створення і налаштування ресурсів інфраструктури, таких як віртуальні машини, бази даних або мережеві компоненти. Часто автоматизується за допомогою таких інструментів, як Terraform або Ansible.

Infrastructure as Code (IaC) — керування та забезпечення інфраструктури за допомогою машинно-читальних файлів конфігурації, а не ручних процесів.

** Дрейф ** — різниця між фактичним станом інфраструктури і бажаним станом, визначеним у IaC. « Ми виявили дрейф у середовищі перевірки — хтось вручну змінив правило групи безпеки. »

** Ідемотентна ** — операція, яка дає однаковий результат, незалежно від того, чи виконується вона один раз, чи декілька разів. Ідемпотенційность є ключовою властивістю надійних скриптів автоматизації інфраструктури.

** Незмінна інфраструктура ** — підхід, за якого сервери ніколи не змінюються після розгортання; замість цього, створюються нові штампи і замінюються старі екземпляри. Це виключає дрейф конфігурації.

** Файл стану ** — у Terraform і подібних інструментах, файл, який записує поточний стан керованої інфраструктури, використовується для обчислення змін, які слід застосувати.

Система контролю та надійності

** SLO (Service Level Objective) ** — внутрішня ціль для надійності послуги, наприклад, 99, 9% доступності протягом 30- днівного вікна. SLO узгоджуються в рамках інженерної команди.

SLA (Service Level Agreement) — договірне зобов’ язання клієнтам щодо якості обслуговування. Порушення SLA може мати фінансові наслідки.

** Бюджет помилок ** — прийнятна кількість ненадійності протягом періоду SLO. Якщо ваш SLO становить 99, 9%, ваш бюджет помилок становить 0, 1% (близько 43 хвилин на місяць). « Ми використали 80% нашого бюджету помилок цього місяця; нам слід призупинити випуски, які не є важливими »

** Будь- де** — зміна, коли інженери доступні поза робочими годинами, щоб відповісти на інциденти. « Я буду на зв’ язку у ці вихідні; будь ласка, уникайте великих змін у п’ ятницю після полудня. »

** Втомлення від попереджень ** — стан, коли надто багато низькоякісних попереджень знижує чутливість інженера, що знаходиться на черзі, і спричиняє упущення важливих попереджень. « Нам слід перевірити пороги попереджень — команда відчуває втомлення від попереджень. »

** Runbook ** — документований набір кроків для реагування на певну оперативну подію або попередження, що надає змогу будь- якому інженеру, який перебуває на зв’ язку, працювати з відомими сценаріями.

Приклади слів у контексті

1. «CI конвеєр створює Docker артефакт на кожному відштовхуванні до головного; ворота розгортання вимагають проходження всіх інтеграційних тестів, перш ніж артефакт буде підвищений до стаджінгу»

2. «Наш стан Terraform показав значний дрейф після вручну hotfix минулого місяця — ми провели спринт, щоб узгодити код інфраструктури з реальністю»

3. «Ми встановили наш SLO на 99,5% успішності запитів, даючи нам бюджет помилок близько 3,6 годин на місяць, щоб поглинути заплановані і незаплановані перерви»

4. «Ідемпотентний дизайн наших скриптів забезпечення означає, що ми можемо безпечно перезапустити їх під час відновлення без ризику створення дублікатів ресурсів»

5. «Після відновлення, інженер на виклику оновив runbook з новим кроком для перевірки стану міграції бази даних перед запуском будь-яких майбутніх розгортань»

Використовує лексику мови гавайців

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

Поняття «неправильний»: неправильний вираз, неправильне розуміння

Для розробників, що походять з різних сфер, навіть здавалося б прості терміни DevOps можуть мати незначні відмінності в значенні і використанні. Це не просто про те, щоб знати визначення “CI/CD”, але розуміти, як це насправді обговорюється в команді. Ключова область, яку часто ігнорують, це розпізнавання прихованих очікувань – що є «доброю» практикою, або «невідкладною» зворотною зв’язком. Давайте розглянемо деякі типові шаблони фразування, з якими ви можете зіткнутися, і як їх ефективно інтерпретувати.

Один з найчастіших сценаріїв включає перегляд коду. Ви отримаєте коментар на зразок: « Ця гілка потребує більш детального оброблення помилок ». Хоча це технічно правильно, але може здатися досить нечітким. Рідний мовець, ймовірно, буде продовжувати з питаннями: «Чи можете ви розібратися, * де * помилки трапляються? Чи ми говоримо про конкретні краї або загальну міцність? » У початковому коментарі не вказано рівень деталізації, який потрібно — людина, для якої мова не є рідною, може інтерпретувати це як необхідність додавання обробки помилок скрізь, що може бути перебільшенням. Аналогічно, повідомлення Slack часто містять скорочену мову, яку потрібно розпакувати. Отримання повідомлення «ПЕРЕВАЖНО: Не вдалося розгорнути» не є просто попередженням; воно викликає такі питання, як «Який вплив? Що є причиною цього?» і «Хто відповідає за цю проблему?». Зрозуміти контекст цих фраз є ключовим для відповідного реагування і уникнення неправильного тлумачення. Метою завжди є чітке спілкування - не вагайтеся попросити про пояснення, якщо щось не відразу очевидно. Сфокусування уваги на тому, * чому* було зроблено запит, а не просто прийняття його як інструкції, значно поліпшить ваше розуміння і співпрацю.

Інша область плутанини часто виникає при обговоренні управління випуском. Фрази на кшталт «блакитно-зелені розгортання» або «канарські випуски» можуть звучати залякуючою на початку. Основна концепція — тестування нових версій з підмножини користувачів перед повним розгортанням — важлива, але конкретна термінологія може відрізнятися. Корисно запитати про докладне пояснення: «Чи можете ви провести мене через процес? Які показники ми контролюємо під час фази канарки? “Це демонструє залученість і гарантує, що ви відповідаєте стратегії. Зверніть увагу на те, як хтось описує процес випуску - їхній тон, рівень деталізації - може багато розповісти про очікування і пріоритети.

І нарешті, пам’ ятайте, що документація - ваш друг. Не бійтеся звертатися до нього для пояснення або консультуватися з старшими членами команди, якщо ви не впевнені в чомусь. Проактивне запитання завжди краще, ніж припущення.

# Example: Using kubectl to describe a deployment and check its readiness probes

kubectl get deployment my-app -n my-namespace -o yaml | grep readinessProbe