How to Explain a Silent Data Corruption Bug in English

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

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

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

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

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

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

** Радіус вибуху (дані) ** — конкретний набір записів, таблиць або систем нижче по течії, які могли бути вражені, відрізняються від записів, які підтверджено вражені, оскільки злиття « могли бути вражені » з « вражені » або недооцінює, або перебільшує справжній вплив. “Радиус вибуху включає приблизно 40 000 записів, записаних під час вікна пошкодження, але ми ще не знаємо, скільки з них було дійсно пошкоджено — ця цифра буде залежати від пропуску примирення, а не тільки від розміру вікна.”

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

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

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

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

Чесно оголосить про відкриття, включаючи те, що ще невідомо:

• “Ми виявили помилку, яка тихо пошкодила підмножину загальних замовлень між 3 березня і 18 квітня. Ми ще не знаємо точну кількість замовлень, які зазнали впливу — ми зараз запускаємо процес примирення і оновимо вас протягом 24 годин з підтвердженими номерами. *

Пояснюючи, чому він так довго не виявлений:

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

Відрізняти потенційне від підтвердженого удару чітко:

• “Вікно пошкодження охоплює близько 40 000 записів, що є верхньою межею того, що може бути пошкоджено. Пропуск примирення підтвердив, що 1200 з них наразі є насправді неправильними — ми очікуємо, що ця кількість зростатиме, оскільки прохід продовжується, але не до повних 40 000. “*

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

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

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

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

Наприклад, англійська мова: англійська мова для немовлят

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

Поширеною пасткою є використання надто технічної мови без контексту. Замість того, щоб сказати « Потік даних не відповідав стандартам серіалізації », краще було б сказати « Ми виявили, що дані не були записані у базу даних коректно, що призвело до невідповідностей ». Зауважте, що у цій версії уникається жаргону і акцентується увага на * ефекті * проблеми — невідповідностях. Аналогічно, при описі процесу відкриття, такі фрази як «ваду було виявлено» звучать різко. Ефективніше сказати: « Ми виявили проблему під час наших рутинних перевірок достовірності даних ». Це підкреслює активний підхід до розв’ язання проблем, який цінується у більшості професійних середовищ. Інша ключова область - це оцінка тяжкості. Замість того, щоб сказати « Це спричинило значні перерви », розгляньте « Це вплинуло на декілька процесів нижче по течії і потребувало негайного усунення ». Останнє передає терміни і вплив без використання перебільшення.

Розглянемо практичний приклад. Уявіть, що ви пишете коментар до запиту на збирання, пов’ язаного з цією проблемою. Замість того, щоб просто сказати « Дані пошкоджено », спробуйте сказати: « Я помітив деякі невідповідності у створенні звіту через потенційні проблеми з оновленням даних. Я почав досліджувати журнали бази даних і можу надати більше деталей, як тільки вони з’ являться.” Ця фраза демонструє, що ви активно працюєте над проблемою і запрошує до співпраці. Крім того, при описі кореневої причини (яка може бути складною) зосередьтеся на * механізмі *, а не на загальному розумінні технічних деталей. « Здається, що відбулася несподівана зміна у форматі даних перед тим, як вони дісталися до служби звітування » буде яснішим, ніж « Незгода схеми спричинила пошкодження »

Нарешті, пам’ятайте, що активне слухання і пояснення є ключовими. Якщо хтось попросить вас пояснити щось далі, не вагайтеся попросити їх розібратися в тому, що вони розуміють. Фрази на кшталт «Чи можете ви розповісти мені більше про те, що ви маєте на увазі під…?» або «Тільки щоб бути ясно, чи розумієте ви, що…» демонструють прихильність до ефективного спілкування і забезпечують, що всі знаходяться на одній сторінці — критична вміння в будь-якій команді розробників.