Як пояснити конфігурацію Drift Issue в англійській мові

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

Ключовий словник

Заявлений стан — конфігурація, яка визначена в коді, контролі версій або інструменті інфраструктури як коду, який має бути єдиним джерелом правди про те, як має виглядати система. “Згідно з оголошеним станом у наших файлах Terraform, ця група безпеки дозволяє лише трафік з внутрішнього VPC — це те, що кожен, хто читає сховище, прийме за правду.”

** Дрифт ** — будь-яка різниця між оголошеним станом і фактичним станом роботи, незалежно від того, як це сталося, що є основною концепцією, яку потрібно назвати явно, а не описувати нечітко як « щось не так »

• “Ми виявили дрейф на дванадцяти ресурсах лише цього тижня. Хтось зробив вручну зміну через консоль під час інциденту три місяці тому, і він ніколи не був прирівняний до стану Terraform. ”*

** Зміна поза діапазоном ** — модифікація, яка здійснюється безпосередньо у живій системі, поза звичайним розгортанням або інфраструктурою як кодом, що є найпоширенішою причиною дрейфу і варто назвати її конкретно, оскільки вона вказує на прогалини у процесі, а не лише на технічні. “Це не була помилка інструменту - це була зміна поза діапазоном, зроблена безпосередньо в консолі під час інциденту о 2 годині ранку, яка є саме таким видом зміни, для якої наш поточний процес не має мережі безпеки.”

** Примирення ** — процес порівняння декларованого і фактичного станів і розв’ язання різниці, або шляхом оновлення коду, щоб він відповідав дійсності, або шляхом повернення дійсності, щоб вона відповідала коду.

• “Примирення тут означає вирішення, ресурс за ресурсом, чи була зміна, внесена вручну, насправді правильною і чи її слід кодувати, чи це була помилка, яку слід відновити, щоб вона відповідала початковому оголошеному стану.” *

Звичайні фрази

• «Існує дрейф між нашим декларованим станом і тим, що насправді працює у виробництві — ось конкретно де вони розходяться»
• «Це, здається, є результатом зміни поза діапазоном, що означає, що наша інфраструктура-як-код більше не відображає реальність»
• «Перед тим, як ми можемо безпечно змінити це далі, нам потрібно примирити дрейф, щоб ми працювали з точної картини»
• «Ризик з непримиреним дрейфом полягає в тому, що наступне розгортання може беззвучно повернути цю зміну, оскільки наші інструменти не знають про це»
• «Я б хотів запустити дрейф-визначення на решті цього середовища, перш ніж ми припустимо, що все інше синхронізовано»

Приклади висловлювань

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

Назва кореневої причини, навіть якщо вона вказує на прогалини у процесі: *“Це відбулося тому, що хтось застосував аварійний виправлення безпосередньо в консолі під час відключення в минулому місяці, що було правильним викликом в цей момент, але воно ніколи не було приведено в порядок в нашій Terraform після цього.” *

Пропонуючи примирення як конкретний наступний крок:

• “Я б хотів примирити цей дрейф кодифікацією ручної зміни, оскільки тестування підтвердило, що це було насправді необхідним виправленням — тоді я перевірю решту цього середовища на будь- що подібне.” *

Професійні поради

• Завжди вказуйте, яка сторона є авторитетною при описі ** декларованого стану ** — скажіть явно, чи код або запущена система є в даний час неправильною, оскільки « вони не збігаються » самі по собі залишають читача не впевненим, чому довіряти.
• Виміряйте ** дрейф **, де б ви не могли, навіть грубо - “дрейф на дванадцяти ресурсах” набагато більш дієвий, ніж “деякі речі дрейфували”, і дає зацікавленим сторонам відчуття обсягу.
• Назвіть ** зміну поза діапазоном ** чесно, не обрамляючи її як звинувачення - більшість змін поза діапазоном відбуваються під час інцидентів під тиском часу, і корисний вивід - це прогалина процесу, а не помилка особи.
• Представте примирення як рішення з двома можливими результатами — кодифікувати дрейфуючий стан або повернутись до оголошеного — замість того, щоб припускати, що виправлення завжди повертає назад.
• Відстежуйте події, пов’ язані з дрейфом, за допомогою пропозиції щодо інструментів визначення дрейфу або періодичного аудиту, оскільки одноразове виправлення без запобігання лише відкладає наступне виникнення тієї ж проблеми.

Практичні вправи

1. Напишіть речення, у якому буде описано відхилення між оголошеним і фактичним станом гіпотетичної конфігурації бази даних.
2. Поясніть, в двох реченнях, зміну поза діапазоном і чому це сталося без приписування вини окремій особі.
3. Запропонуйте речення плану примирення, яке називає обидва можливі результати: кодифікувати або відновити.

Національні мови: мова рідних, мова нерідних

Пояснення конфігурації дрейфу не просто про те, що це відбувається; це про комунікацію впливу цього дрейфу таким чином, щоб кожен міг зрозуміти. Для розробників, чия основна мова не є англійською, це часто означає боротьбу зі спеціалізованою термінологією і нюансованими фразами. Давайте розглянемо деякі поширені пастки і створимо словник, спеціально підготовлений для ефективного передачі цих питань. Ключова концепція полягає в розумінні того, що «дрейф» сам по собі має певну конотацію — він передбачає небажане відхилення від бажаного стану. Використання сильніших дієслів, ніж просто «змінено», може значно поліпшити ясність. Замість того, щоб сказати « Налаштування змінилося », розгляньте такі фрази, як « налаштування розбіглися » або « налаштування відхилилися »

Одна з часто зустрічається ситуацій під час перегляду коду. Уявіть, що ви переглядаєте запит на звантаження, у якому рядок з’ єднання з базою даних у виробничому середовищі було випадково змінено. Спочатку вам може здатися, що ви просто скажете: « Ця зміна налаштувань потребує уваги ». Але це не зовсім правильно. Ефективнішим підходом для когось, хто вивчає професійну англійську, буде: «Я помітив розбіжність у рядку з’єднання бази даних між нашими середовищами розробки і виробництва. Це є потенційним ризиком для безпеки, оскільки це може призвести до [коротко пояснити вразливість — наприклад, несанкціонований доступ], якщо не буде негайно виправлено. ” Зверніть увагу на використання точної мови, наприклад, « відхилення » або « відхилення », які безпосередньо стосуються проблеми, а не покладаються лише на опис дії (« змінено »). Аналогічно, під час документування опису PR, уникайте фраз на кшталт « виправлена проблема конфігурації ». Замість цього використовуйте: « Розв’ язано випадки зміни налаштувань, що впливає на рядок з’ єднання з виробничою базою даних. Ця зміна вводить потенційну вразливість безпеки і вимагає негайного усунення»

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