DevOps English Vocabulary: CI/CD, Infrastructure-as-Code, and Incident Management (англійською)
Освоєння англійської лексики, яку інженери DevOps використовують щодня — термінологія конвеєра, мова інфраструктури як коду, фрази на виклик і комунікація управління інцидентами.
DevOps має свій власний діалект. Коли ви приєднуєтесь до команди, яка управляє трубопроводами, керує інфраструктурою за допомогою коду, і реагує на інциденти о 2 годині ночі, вам потрібно розуміти слова, які використовують ваші колеги, і використовувати їх правильно. Неправильне використання таких термінів, як «rollback» проти «roll forward», або плутанина «deploy» з «release», може призвести до дорогих нерозумінь. Цей посібник містить словник, який інженери DevOps, SRE та інженери платформи використовують на зустрічах, в Runbooks та каналах Slack щодня.
Термінологія CI/CD Pipeline
Неперервна інтеграція і неперервна доставка є хребетом сучасної доставки програмного забезпечення. Ці терміни з’ являються у описах робіт, обговореннях архітектури і коментарях перегляду коду.
** Конвейєр ** — автоматизована послідовність кроків, які збирають, перевіряють і розгортають код. « Конвейєр зазнав невдачі на етапі тестування інтеграції — хтось надіслав зміну, яка призвела до пошкодження »
** Фаза / Крок ** — дискретна фаза у конвеєрі. Поширені стадії включають build, test, lint, security-scan, deploy-staging, deploy-production. “The deploy-prod stage requires manual approval before it runs.”
** Тригер ** — подія, яка запускає запуск конвеєра. Тригери включають події відсилання, створення запитів на відвантаження, об’ єднання PR, заплановані завдання cron або вручну відправлені завдання. « Ми додали тригер, щоб конвеєр запускався автоматично під час кожного відсилання до гілки main. »
** Артефакт ** — файл або пакунок, створений на етапі збирання і переданий на наступні етапи. Всі штампи Docker, збірки бінарних файлів і звіти про тестування є артефактами. « Сховища конвеєра збирають артефакти протягом 30 днів, щоб ми могли знову розгорнути будь- яку попередню версію. »
** Зелена збірка / Червона збірка ** — неформальні терміни для успішного (зеленого) або невдалого (червоного) запуску конвеєра. « У нас є правило: ніколи не об’ єднувати, якщо збірка червона. » « Після виправлення помилки у тесті збірка стала зеленою. »
** Флакі тест ** — тест, який іноді успішно проходить, а іноді зазнає невдачі без будь- яких змін у коді. « У наборі програм є три флакі- тести, які спричиняють періодичні помилки конвеєра — нам слід виправити їх або поставити їх під карантин. »
** Частота розгортання ** — як часто код розгортається у виробничій середовищі. Ключовий показник DORA. « Частота розгортання — 15 разів на день — ми автоматично розгортаємо кожен об’ єднаний PR »
** Час виконання змін ** — час від затвердження коду до його запуску у виробничій оболонці. « Зменшення часу виконання з трьох днів до чотирьох годин було нашою головною метою CI/ CD цього кварталу. »
Мова програмування — англійська
Infrastructure-as-Code (IaC) означає визначення серверів, мереж і сервісів в коді, а не клацання через інтерфейс користувача. Словник технічний, але специфічний.
** Обладнання ** — для створення і налаштування ресурсів інфраструктури. « Ми обладнуємо кластер бази даних за допомогою Terraform під час кожного створення середовища ». На відміну від ** відключення обладнання **: для знищення ресурсів.
** State ** — у таких інструментах, як Terraform, збережений запис про те, яка інфраструктура існує на даний момент, використовується для обчислення змін, які потрібно внести. « Файл стану Terraform відхилився від реальності, оскільки хтось вніс зміни вручну у консолі AWS. »
** Дрейф ** — коли фактичний стан інфраструктури відрізняється від того, що визначено у коді. « Ми запускаємо дрейфове виявлення щоночі, щоб виявити будь- які зміни, які відбуваються вручну, і які обходять наш робочий процес IaC. »
** Ідемотентна ** — операція, яка дає однаковий результат незалежно від кількості її виконань. Інструменти IaC розроблені таким чином, щоб бути ідемпотентними. « Ансибельні книги ігор повинні бути ідемпотентними — їх двічі запуск нічого не змінить під час другого запуску. »
** Модуль ** — самостійний модуль налаштування IaC, який можна використовувати знову і знову. « У нас є спільний модуль VPC, який кожна команда імпортує, щоб забезпечити послідовне налаштування мережі. »
** План / Застосувати ** — двох кроків процес Terraform: plan показує, які зміни буде внесено; apply виконує їх. « Завжди ретельно переглядайте вивід плану перед застосуванням — план показує вам, що саме буде створено, змінено або знищено. »
** Незмінна інфраструктура ** — практика заміни серверів, а не їх зміни на місці. « Ми дотримуємося принципів незмінної інфраструктури: замість того, щоб латити запущений екземпляр, ми створюємо нову AMI і замінюємо її. »
Фрази управління інцидентами
Інциденти є звичайною частиною роботи виробничих систем. Мова, використовувана під час і після інциденту, є формальною, точною і відповідає певним конвенціям.
** Інцидент ** — незапланована подія, яка погіршує або перериває роботу служби. Інциденти класифікуються за ступенем тяжкості: SEV1 (критичний), SEV2 (головний), SEV3 (незначний). « Ми маємо інцидент SEV1 — служба оплати повертає 500 помилок для всіх користувачів. »
** На гарячій лінії ** — послідовність інженерів, відповідальних за відповідь на попередження поза робочими годинами. « Я на гарячій лінії цього тижня, тому мій телефон працює гучно ». « Хто зараз на гарячій лінії команди платформи? »
** Page / alert ** — сповіщення, яке буде надіслано інженеру, коли буде перевищено пороговий рівень спостереження. « Мене викликали о 3 годині ранку, оскільки затримка перевищила пороговий рівень SLO. »
** Триаж ** — процес оцінки та приоритизації масштабу та тяжкості інциденту. “Якщо було викликано попередження, команда розглядала проблему протягом п’ яти хвилин і підвищила її до SEV1.”
** Ескалація ** — для залучення більшої кількості людей або старших працівників, коли інцидент не може бути розв’ язано швидко. « Якщо ви не знайдете кореневу причину протягом 30 хвилин, ескалуйте до інженерного керівництва. »
** Зменшення шкоди ** — дія, яку було виконано для зменшення впливу інциденту, навіть якщо кореневу причину не було виправлено. « Для зменшення шкоди ми збільшили розмір пулу з’ єднань — частота помилок негайно зменшилася. »
** Відновлення ** — повернення до попередньої робочої версії програмного забезпечення або налаштувань. « Ми відновили розгортання о 11: 47 і служба відновилась протягом двох хвилин. »
** Postmortem / Post- incident review ** — документ, написаний після інциденту, який пояснює, що сталося, чому це сталося, який був вплив, і які дії запобігнуть повторенню. “В результате вскрытия были выявлены три фактора, способствовавшие этому: отсутствие автоматического выключателя, неадекватное оповещение и недостаточное тестирование нагрузки на этапе”
** Корінь причини ** — основна причина, з якої стався інцидент, а не лише безпосередній симптом. « Корінь причини — це витік пам’ яті, який було введено у випуску за два дні до інциденту. »
Спостережливість і моніторинг лексики
** Спостережливість ** — здатність розуміти внутрішній стан системи з її зовнішніх виходів (журналів, метрик, трасування). « Ми вклали кошти у інструменти спостережливості цього кварталу — тепер ми можемо трасувати будь- який запит з шлюзового інтерфейсу API до бази даних. »
** SLO (Service Level Objective) ** — внутрішня ціль, яка визначає наскільки надійною має бути служба. « Нашою SLO для API замовлення є 99, 9% доступності і затримка p99 менше 300 мс. »
** SLA (Service Level Agreement) ** — формальне, контрактне зобов’ язання клієнтам щодо надійності обслуговування. « Наш SLA гарантує 99, 5% часу роботи; порушення викликають кредити клієнта. »
** Бюджет помилок ** — кількість перерв або помилок, які можна дозволити службі, але при цьому не перевищувати її SLO. « Ми використали 80% нашого бюджету помилок цього місяця — ніяких ризикованих розгортань до наступного місяця. »
** MTTR (середній час відновлення) ** — середній час від початку інциденту до відновлення роботи служби. « Покращення наших книг виконання скоротило MTTR з 45 хвилин до 12 хвилин. »
Практичні вправи
Перевірте ваші знання з DevOps за допомогою таких завдань:
-
** Перегляд конвеєра: ** Читання налаштувань YAML потоку дій GitHub або потоку CI GitLab. Определите каждую стадию, триггер и артефакт. Напишіть резюме англійською мовою у одному абзаці, у якому буде описано, що робить конвеєр.
-
** Імітація інциденту: ** Прочитайте публічне пост-мортем (Google, Cloudflare і Stripe опублікували їх). Визначте кроки сортування, дії зменшення ризику і кореневу причину. Підсумуйте хронологію вашими словами.
-
** Відображення словника IaC: ** Відкрийте сховище Terraform або Ansible на GitHub. Знайдіть приклади модулів, посилань на стани і операцій із іменем. Примітте кожну з них правильним словниковим терміном.
-
** Написати міні- підручник з керування: ** Виберіть просте завдання (наприклад, перезапуск служби, масштабування розгортання) і напишіть його англійською мовою, ніби ви пишете підручник з керування для нового члена команди. Використовуйте принаймні п’ ять слів з цієї статті.
Практикуйте використання цих термінів у контексті, відвідавши Вправи з DevOps & Cloud vocabulary на Coders Lingo.