Справа з помилками, що не відтворюються

Припустимо, ваша команда пише програмну систему, яка (досить дивно!) Працює нормально.

Одного разу один з інженерів помилково запускає деякі запити SQL, які змінюють деякі дані БД, а потім про них забуває.

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

Як ти з цим справляється?

Очевидно, що жоден керівник проекту не вкладе нескінченну кількість часу в таку проблему. Вони хочуть не допустити повторення тієї ж ситуації.

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

• Виявляйте такі збої раніше, якщо вони повторюються
• Зробіть меншою ймовірність, що той самий збій повториться
• Зробіть систему більш надійною щодо конкретного виду непослідовної

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

Подумайте, який відповідний вид може бути у вашій ситуації, і запропонуйте це команді; Я впевнений, що ваш керівник проекту буде задоволений.

Одного разу один з інженерів помилково запускає деякі запити SQL, які змінюють деякі дані БД, а потім про них забуває.

Як зазначають інші, також непогано заборонити таку процедуру (якщо ви впливаєте на функціонування системи). Ніхто не повинен дозволяти виконувати незадокументовані спеціальні запити, які змінюють вміст бази даних. Якщо є необхідність у такому запиті, переконайтеся, що існує політика щодо зберігання запиту разом із датою його виконання, іменем особи, яка його виконала, та причиною його використання в документально підтвердженому місці.

Це не помилка

Принаймні, не на ваш код. Це помилка у вашому процесі . Ваш керівник проекту повинен набагато більше турбуватися про ваш процес, ніж про ваш код.

Як ти з цим справляється?

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

Якщо припустити, що це спільна база даних розробок:

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

Якщо з якоїсь причини ви абсолютно ОБОВ'ЯЗКОВО маєте спільну базу даних, вам слід використовувати світильники - по суті, те, що встановлює базу даних у добре відомий стан кожного разу, коли вам потрібно її використовувати. Це дозволяє уникнути, що розробники не будуть покусані змінами інших людей.

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

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

Припустимо, що це виробнича база даних:

Якщо ваші розробники змінюють виробничі бази, багато речей пішли жахливо неправильно, навіть якщо зміни абсолютно правильні.

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

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

Якщо вам потрібно щось перевірити у виробничій базі даних ... ні, ви цього не робите. Які б тести вам не потрібно було робити, ви повинні робити в екземплярі розробки. Якщо вам потрібні деякі дані, щоб зробити тести, ви отримаєте ці дані там.

Виробнича база даних повинна мати повний журнал доступу та управління доступом на основі ролей. Таким чином, ви повинні мати вагомі докази того, хто робив, ЩО КОГО ДО БД, тим самим переводячи увагу з коду на слабку операційну безпеку.

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

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

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

По-третє, стійкість. Помилки неминучі, тому запитайте себе, як ви можете покращити ваші системи, щоб бути більш стійкими, щоб відновлення помилки було простіше. Чи можна було б покращити (чи існувати) ваші резервні копії? Краще спостереження, відмова та сповіщення? Більше надмірності? Краще поводження з помилками? Розв’язати залежні послуги один від одного? Чи можете ви покращити свої процеси щодо доступу до бази даних та запитів вручну? У кращому випадку ці речі зроблять наслідки вашої помилки менш серйозними, а в гіршому - вони, мабуть, добрі речі все одно робити.

1. Поясніть менеджеру проектів, що, на вашу думку, найбільш ймовірною причиною є ручний доступ до бази даних.
2. Якщо вони все ще хочуть, щоб ви шукали код, який це спричинив, перейдіть і ще раз подивіться на код.
3. Поверніться через пару годин (або якийсь інший відповідний час) і скажіть, що ви не можете знайти жодного коду, який би це спричинив, тому ви все ще вважаєте, що найбільш ймовірною причиною є ручний доступ до бази даних.
4. Якщо вони все ще хочуть, щоб ви шукали код, запитайте, скільки часу вони хотіли б, щоб ви витратили на це. Тонко нагадуйте їм, що ви не будете працювати над функцією X, помилкою Y або розширенням Z під час цього.
5. Проведіть стільки часу, скільки вони просять. Якщо ви все ще вважаєте, що найбільш ймовірною причиною є ручний доступ до бази даних, скажіть їм це.
6. Якщо вони все ще хочуть, щоб ви шукали код, розгортайте проблему, оскільки це явно стало непродуктивним використанням часу вашої команди.

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

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

Крок 0: допоможіть клієнту встати та запустити його знову, відновивши базу даних.

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

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

Крок 2: Потім ми внесли дві зміни в програмне забезпечення: (а) ускладнило випадковий спричинення цього ефекту через користувальницький інтерфейс "так, я знаю, що я роблю", і (б) ввести новий файл журналу, щоб, якщо колись це повторювалося, ми б мали записати дії користувачів.

Отже, в основному (а) відновлюйте ушкодження та відновлюйте живий біг, (б) знаходите першопричину, (в) робіть все необхідне, щоб запобігти її повторному зростанню, або щоб увімкнути просту діагностику, якщо вона повториться.

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

Виробнича база даних повинна мати повний журнал доступу та управління доступом на основі ролей. Таким чином, ви повинні мати вагомі докази того, хто робив, ЩО КОГО ДО БД, тим самим переводячи увагу з коду на слабку операційну безпеку.

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

Десь має бути така цитата, якщо ні, ви можете мені процитувати її:

Існує цілком вагома причина, щоб кухарі не відповідали за очищення туалетів.

Є кілька речей, які необхідно зробити з помилками, що не відтворюються.

1. Створіть для нього квиток

Створіть квиток і запишіть все, що ви можете придумати у квитку. Також перевірте, чи раніше ця помилка була зареєстрована, і зв’яжіть квитки разом. Врешті-решт, у вас може бути достатньо квитків, щоб встановити схему, як відтворити помилку. Сюди входять робочі кола, які намагаються уникнути цього. Навіть якщо це єдиний екземпляр, якщо відбудеться перший раз, зрештою буде другий раз. Коли ви дійсно знайдете причину, закрийте квиток із поясненням того, що було причиною, щоб ви мали чітке уявлення про те, що сталося, якщо це повториться (виправити втрачене внаслідок поганого злиття)

2. Зробіть аналіз загартовування

Подивіться на систему, що не вдалось, і як воно вийшло з ладу. Спробуйте знайти код коду, який можна оновити, щоб зробити помилку менш ймовірною. Деякі приклади ...

• Замініть спеціальний код спеціальним викликом (наприклад, execute(<query>)зexecuteMyStoredProcedure(<params>)
• Запускайте нічні сценарії перевірки для перевірки цілісності даних (щоб це можна було виявити протягом 24 годин наступного разу)
• Додати / покращити ведення журналів та архівування (резервне копіювання).
• Змінення неналежних обмежень безпеки (наприклад, люди / програми, які лише читають дані, не мають дозволу на запис; не дозволяють розробникам, які не відповідають за виробництво, не входити на виробничі сервери)
• Додайте перевірку / санітарні дані, якщо вони відсутні

Це може не виправити помилку, але навіть якщо цього не відбувається, система тепер стабільніша / захищена, тому все одно окупається.

3. Додайте системні сповіщення

Деяка частина 2, але щось сталося, і вам потрібно знати, коли це повториться. Вам слід створити кілька сценаріїв / програм перевірки стану здоров’я для моніторингу системи, щоб адміністратори могли попередити протягом 24 годин після появи помилки (чим менше затримка, тим краще в межах причини). Це набагато полегшить прибирання. (Зауважте, що окрім журналів баз даних, ОС має також здійснювати реєстрацію тих, хто входить до неї, та будь-які нечитані дії, які вони виконують. Принаймні, повинні бути мережеві журнали трафіку на цій машині)

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

Якщо ви називаєте помилки у вашій базі даних «помилками», то у вас немає невідтворюваної помилки, у вас немає помилки. Ви можете мати звіт про помилку, але у вас є також докази того, що проблема не була викликана помилкою. Таким чином, ви можете закрити звіт про помилку, не як "невідтворюваний", а щось інше, як "пошкоджена база даних". Не рідкість наявність звітів про помилки, коли розслідування показує, що немає помилки, але користувач невірно користувався програмним забезпеченням, очікування користувачів були помилковими тощо.

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