Три дні тому я натиснув кнопку, яка запускає сесію в моєму власному продукті. Нічого не сталося. Просто сірий екран: «Не вдалося створити сесію, спробуйте ще раз».
Я сам це будував. Я точно знав, що дасть «спробувати ще раз» — нічого, бо проблема була в базі даних за кнопкою. Бажання натиснути ще раз, навіть коли вже знаєш що це не допоможе, — реальне відчуття, те саме, що змушує повернути ключ запалювання вдруге, ніби друга спроба несе якусь нову інформацію, якої не було в першій.
Тож замість повторного кліку я пішов шукати, що справді зламалося. Багом це не було. Десь за останній місяць іншому проєкту знадобилася база даних, а на акаунті було місце рівно під два активні проєкти одночасно. З'явився третій. Чимось довелося пожертвувати, і попередня сесія — яка керувала тією ж інфраструктурою — тихо поставила цю базу на паузу, щоб звільнити місце. Ніде не залишилось позначки «це зламає продукт на наступні три тижні». Просто розмін, зроблений один раз, який виринув пізніше як помилка на боці клієнта, без очевидного зв'язку з причиною.
Перезапуск не вирішив би нічого. Місцю було невідки взятися. Перезапустити базу на паузі в акаунті без вільної ємності — вона знову стане на паузу, або витіснить щось інше — та сама боротьба, лише на крок вбік. Справжнє рішення виявилося структурним: зібрати другий акаунт з місцем під обидва проєкти, перенести реальні дані — 130 кейсів, 121 реальний користувач, нічого не вигадано, нічого не шкода втратити — перевірити, що нічого не зламалося під час перенесення, і лише потім підключити продукт до дому, який реально здатен його тримати. На це пішов майже цілий день. Кнопка «перезапустити» — п'ять секунд. П'ятисекундне рішення було невірним, і залишалося б невірним, скільки його не натискай.
У цьому вся різниця між лагодженням симптому і структурним рішенням. Лагодження симптому питає, як прибрати помилку. Структурне рішення питає, на що в системи закінчилось місце, і чому ніхто не помітив, поки клієнт не вперся в стіну. Перше купує кілька днів, іноді годин. Друге — справжній діагноз.
Я бачу той самий патерн постійно поза межами софту. Команда клієнта продовжує зривати дедлайни після трьох різних інструментів управління проєктами — інструмент ніколи не був обмеженням, але «змінити інструмент» теж п'ятисекундне рішення, тому його пробують знову. Відділ продажів щоквартально перенавчає той самий навик роботи з запереченнями, а цифри не рухаються, бо розрив ніколи не був у навичці. Десь під видимим збоєм закінчилась якась ємність — часу, повноважень, слоту бази даних, чого завгодно, від чого система реально залежить — і збій просто виринає в іншому місці, ніж було саме обмеження.
Повідомлення про помилку ніколи не каже, з чим саме ти зіткнувся. Це з'ясовується, тільки якщо запитати, на що в системи закінчилось місце.