DevOps Vocabulary: 40 Must-Know Terms (англійською)
Практичний посібник з 40 найважливіших термінів DevOps — від конвеєрів CI/CD і контейнерів до моніторингу, IaC і стратегій розгортання. З прикладними реченнями для кожного терміна.
DevOps має свою власну мову. Якщо ви працюєте розробником, SRE, інженером з розробки платформ або інженером з контролю якості — або просто намагаєтеся слідкувати за технічною дискусією, яка стосується конвеєрів розгортання — цей словник є обов’ язковим.
Ця стаття пояснює 40 ключових DevOps термінів, згруповані за категоріями, з прикладними реченнями, що показують, як кожен термін фактично використовується в розмові і документації.
Підтримка C/C++
- Нет, не надо Автоматична послідовність кроків, які переносять код з перенесення до виробничого стану. Кожен крок називається * стадією *, і стадії виконуються в порядку.
- « Конвейер зазнав невдачі на етапі тестування — це схоже на відсутність змінної середовища. » *
Сцена Відмінний етап у конвеєрі: збирання, тестування, розгортання тощо. Стадії можуть бути послідовними або паралельними.
“Ми запускаємо тести модулів та тести інтеграції паралельно, щоб скоротити час виконання конвеєра.”
Артефакт Файл або набір файлів, створених на етапі збирання і переданих на наступні етапи. Образи Docker, скомпільовані бінарні файли і звіти про покриття — це всі артефакти.
“Стадія збирання створює артефакт Docker, який буде відправлено до реєстру.”
Тригер Подія, яка запускає виконання конвеєра. Серед типових тригерів — відсилання до гілки, запит на об’ єднання або запланований час.
- “Ми налаштували тригер на кожному відсиланні до головної гілки.” *
Бегун Машина або контейнер, який виконує завдання конвеєра. Запуски можуть бути самостійно розміщені або надані платформою CI.
- « Завдання в черзі — нам може знадобитися додати ще одного виконавця, щоб прискорити процес ». *
Веб- гаук Зворотний виклик HTTP, надісланий однією системою до іншої, коли відбувається подія. GitHub надсилає webhook на ваш сервер CI, коли ви надсилаєте код.
“Налаштувати webhook, щоб Slack сповіщав нас про успішне розгортання.”
Окружающая среда
Назва конфігурації інфраструктури: зазвичай development, staging, і production. Кожне середовище може мати різні секрети, з’ єднання з базами даних і обмеження ресурсів.
- “Ця зміна знаходиться на стадії розробки — ми перенесемо її до виробничого режиму після підписання QA.” *
Контейнери і оркестрація
Контейнер Невелике, ізольоване середовище виконання, яке пакує програму і її залежності. Контейнери стандартизовані, портативні і швидше запускаються, ніж віртуальні машини.
“Ми надаємо наші послуги як контейнери, тому вони працюють однаково в dev, staging і prod.”
Зображення Шаблон тільки для читання, який використовується для створення контейнерів. У штамп включено базу ОС, код програми і залежності. Зображення зберігаються у реєстрі.
“Позначте штамп SHA-кодом затвердження, щоб ми могли відстежити кожну збірку до її джерела.”
** Реєстр ** Система зберігання і розповсюдження контейнерних штампів. Docker Hub, AWS ECR, і Google Artifact Registry є поширеними прикладами.
- “Підштовхнути штамп до реєстру після стадії збирання, а потім витягнути його на стадії розгортання.” *
- Под Найменший розгортальний блок у Kubernetes. Підрозділ містить один або декілька контейнерів, які мають спільний мережевий простір назв і сховище.
- “Коли підсистема зламалася, Kubernetes автоматично перезапустила її.” *
Кластер Група вузлів (машин), якими керує Kubernetes, які виконують контейнеризовані завдання разом.
“У нас є виробничий кластер в us-east-1 і кластер для перевірки в eu-west-1.”
** Простір назв ** Логічний розділ у кластері Kubernetes, який використовується для відокремлення середовищ або команд.
“Команда з платежу розгортає все в просторі імен
payments, щоб ізольувати свої ресурси.”
Вузли Одна машина (віртуальна або фізична) у кластері Kubernetes. Планувальник кластерів призначає підкластри вузлам на основі наявних ресурсів.
- “Вузол знаходиться під тиском пам’ яті — нам слід або масштабувати його, або збільшити розмір вузла.” *
Оркестрація Автоматизоване керування контейнеризованими застосунками на декількох вузлах: планування, масштабування, мережеві зв’язки і самолікування.
“Kubernetes обробляє оркестрацію, тому ми не маємо вручну керувати тим, де працює кожна служба.”
Контроль і надійність
** SLA (Договір про рівень обслуговування) ** Договір між постачальником послуг і клієнтом, який визначає мінімальні прийнятні стандарти обслуговування — зазвичай, відсоток часу роботи, час відповіді або час відповіді на запит підтримки.
- “Наша угода з клієнтом гарантує 99,9% часу роботи за календарний місяць.” *
** SLO (Ціль рівня обслуговування) ** Внутрішня мета для надійності обслуговування, зазвичай суворіша, ніж SLA. SLO - це те, на що ви націлені; SLA - це те, що ви обіцяєте.
“Наше SLO для API замовлення — p95 < 200 мс. Ми зараз на 215 мс — поза ціль.»
** SLI (індикатор рівня обслуговування) ** Метрика, яку вимірюють для оцінки продуктивності у порівнянні з SLO. Поширені SLI включають частоту помилок, затримку і доступність.
“SLI, який ми відстежуємо для доступності: успішні запити ÷ загальна кількість запитів протягом 30-денного вікна.”
Помилка бюджету Дозволена межа невдачі перед порушенням SLO. Якщо ваш SLO має 99, 9% часу роботи, ваш бюджет помилок становить 0, 1% — близько 43 хвилин простою на місяць.
- “Ми витратили 60% нашого бюджету на помилки цього місяця. Не ризикуйте розгортанням, поки вікно не скинеться».*
Попередження Сповіщення, яке буде викликано, якщо метрика перевищить визначений поріг. Попередження можуть розбудити інженерів під час інциденту (PagerDuty) або опублікувати в Slack для обізнаності.
- “Попередження викликане тому, що затримка p99 перевищила 500 мс протягом 5 хвилин поспіль.” *
По приглашению Ротация, где инженеры берут на себя ответственность за реагирование на инциденты вне рабочего времени.
“Я на этом неделе в дежурстве, поэтому мне нужно держать телефон рядом ночью.”
** MTTR (середній час відновлення) ** Середній час, який знадобиться для відновлення служби після аварії. Чим нижче, тим краще.
“Наша MTTR для P1 інцидентів становить 47 хвилин - середнє значення в галузі близько 60.”
** MTBF (середній час між помилками) ** Середній час між інцидентами. Використовується для вимірювання надійності системи.
“Збільшення MTBF є довгостроковою метою надійності - ми націлюємося на шість місяців між основними відключеннями.”
Книга походів Документована процедура виконання певного операційного завдання або відповіді на певний тип події.
“Дійте за інструкціями для перезавантаження бази даних — вони в опс-вікі під ‘інциденти’.""
Інфраструктура як код (IaC)
**IaC (Інфраструктура як код) ** Керування та забезпечення інфраструктури за допомогою файлів налаштувань, які можна читати машиною, а не вручну.
“З IaC, будь-який інженер у команді може створити нове середовище, використовуючи ті ж самі налаштування Terraform.”
- Не можу Дія, яка дає однаковий результат, незалежно від того, чи виконується вона один раз, чи багато разів. Інструменти IaC мають на меті бути ідемпотентними: повторне виконання apply не повинно змінювати систему, яка вже знаходиться в бажаному стані.
“Terraform apply є idempotent — повторне запуску після відсутності змін нічого не робить.”
Декларативно Описувати, як має виглядати інфраструктура, а не як її побудувати. Маніфести Terraform і Kubernetes є декларативними.
“Маніфест Kubernetes декларує бажаний стан — рівнина управління визначає, як його досягти.”
Наказ Вказівка кроків, які слід виконати для досягнення бажаного стану. Скрипти Bash і Ansible playbooks часто є імперативними.
“Старий підхід був імперативним — двадцять команд оболонки в послідовності, які мали бути виконані у правильному порядку.”
Дрейф Різниця між оголошеним станом інфраструктури і фактичним станом. Дрейф відбувається, коли хтось робить вручну зміну, яка обходить інструменти IaC.
- “Ми виявили дрейф у виробничому кластері — хтось вручну змінив масштаб розгортання без оновлення налаштувань.” *
Провизор Процес налаштування інфраструктури: виділення ресурсів, налаштування правил мережі і встановлення програмного забезпечення.
- “Обладнання нового середовища зазвичай займало два дні. З IaC, це займає близько 15 хвилин.”*
** Стан (Терраформа) ** Файл, який відстежує поточний стан керованої інфраструктури. Terraform порівнює стан з вашими налаштуваннями, щоб визначити, які зміни слід внести.
“Стан Terraform зберігається в S3, а блокуванням займається DynamoDB.”
Стратегия развертывания
Канарський розгортання Стратегія, за якої нова версія спочатку буде розгорнуто для невеликого відсотка користувачів або серверів, спостерігати за помилками, а потім поступово розширювати.
“Ми робимо канарське розгортання — 5% трафіку потрапляє в нову версію протягом 24 годин до повного розгортання.”
Синьо-зелене розгортання Стратегія з двома однаковими середовищами: одне активне (синє) і одне неактивне (зелене). Новий код розгортається на зеленому, перевіряється, а потім трафік переключається. Відновлення відбувається миттєво.
“Синьо-зелена - наша стратегія для розгортання без перерв — ми перевертаємо балансувальник навантаження, коли ми готові.”
Поступово розгортається Стратегія, у якій нові екземпляри поступово замінюють старі. У будь-який момент під час розгортання, як старі, так і нові версії обслуговують трафік.
- “Розгортання з послідовним оновленням оновлює один модуль за раз, тому ми завжди зберігаємо пропускну здатність.” *
** Прапорець можливості ** Метод для вмикання або вимикання можливості під час виконання без перерозгортання коду. Корисно для темного запуску, A/B-тестування і поступового розгортання.
“Новий алгоритм пошуку знаходиться за прапорцем можливостей — ми спочатку ввімкнемо його для 10% користувачів.”
Відкат Повернення розгортання до попередньої версії після інциденту або невдалого розгортання.
“Відповідь призвела до збільшення кількості помилок 5xx — ми повернули попередню версію протягом 3 хвилин.”
** Hotfix ** Невідкладний виправлення розгортається безпосередньо до виробництва, зазвичай, обходячи звичайний цикл випуску.
- “У prod є критичний обхід автентифікації — нам потрібно негайно виправити це.” *
Як використовувати цей словник на практиці
Читання визначення - це початок. Це вільне мовлення є метою. Ось три способи:
** 1. Спостереження за технічними переговорами** Перегляд конференцій на YouTube (KubeCon, HashiConf, AWS re:Invent). Зробіть паузу після кожного речення і повторіть його вголос. Зверніть увагу на те, як спікери описують конвеєри, інциденти і розгортання.
**2. Розповідь про власну роботу Коли ви щось розгортаєте, напишіть або скажіть вголос речення: * « Я створив конфігурацію Terraform, яка декларативно забезпечує VPC і три підмережі. » * Це створює звичку використовувати технічну англійську в реальному контексті.
** 3. Читаю результаты обследования погибших Сайти, такі як GitHub’s Post-Mortem Archive (англійською) і Історія міста Харкова містять автентичну, докладну DevOps англійську. Зверніть увагу, як описуються події, як написані хронології, і як пояснюються рішення.
Швидка реакція
| Term | One-line definition |
|---|---|
| Pipeline | Automated steps from commit to production |
| Artifact | File produced by a build stage |
| Pod | Smallest unit in Kubernetes |
| SLA | Contract-level service guarantee |
| SLO | Internal reliability target |
| SLI | Metric used to measure performance |
| Error budget | Allowed failure margin before SLO breach |
| MTTR | Average time to restore after incident |
| IaC | Infrastructure managed via code |
| Idempotent | Same result no matter how many times applied |
| Drift | Gap between declared and actual state |
| Canary | Gradual rollout to small audience |
| Blue-green | Switch traffic between two identical environments |
| Feature flag | Toggle feature on/off without redeployment |
| Rollback | Revert to previous version |
Створення цього словника не відбувається за одну ніч. Найефективнішим підходом є послідовне визначення: читайте документацію щодо інструментів, якими ви користуєтеся, стежте за публічними звітами про інциденти і вправляйтеся у використанні термінів у письмовій та розмовній формі. Щоразу, як ти використовуєш слово “імпотентний” в обговоренні, воно трохи більше прилипає.