В управлении IT-услугами (ITIL) секрет успеха часто кроется не в героических подвигах, а в умении учиться на своих ошибках и не наступать на одни и те же грабли. Именно для этого существует Known Error Database (KEDB) — база данных известных ошибок. Это хранилище, где фиксируются проблемы, с которыми уже сталкивались, способы их временного обхода (workaround) и (если есть) пути окончательного решения.
Чтобы понять KEDB, нужно разобраться с тремя ключевыми терминами: инцидент, проблема и известная ошибка.
- Инцидент (Incident) — это незапланированное нарушение работы сервиса. Например, перестала работать корпоративная почта.
- Проблема (Problem) — это причина, стоящая за инцидентом. В примере с почтой это может быть, скажем, зависшая критическая служба на почтовом сервере.
- Известная ошибка (Known Error) — это проблема, после того как её причина уже выявлена. Теперь о ней известно, и можно хотя бы примерно понимать, что делать.
Зачем нужна KEDB?
Представьте: у вас упала почта. Специалисты провели диагностику, нашли, что зависла служба, перезапустили её — работа восстановилась. На это ушло, допустим, два часа. Если такого рода инцидент случится снова, и у команды под рукой будет KEDB, где записан прошлый случай со всеми симптомами и решением, второй раз на диагностику может уйти не два часа, а 15 минут. Просто заглянули в базу, увидели, что похожая ситуация уже была, и сразу начали с проверки той самой службы.
Без KEDB каждая проблема решается с чистого листа — команда каждый раз «изобретает велосипед». Это медленно, дорого и не даёт организации становиться зрелее.
Workaround vs. постоянное решение
Важно понимать разницу между временным обходом (workaround) и постоянным решением (permanent fix), потому что в KEDB хранятся именно известные ошибки, для которых на данный момент есть только workaround.
- Workaround (временное решение). Это способ быстро восстановить сервис, не устраняя первопричину. Например, в случае с зависшей службой можно просто перезапустить её. Почта заработает, но проблема вернётся. Workaround нужен, чтобы как можно быстрее вернуть пользователей к работе.
- Постоянное решение. Это устранение коренной причины. В примере с почтой — выяснить, почему служба зависает, и исправить это навсегда (например, применить патч или изменить конфигурацию).
Классическая бытовая аналогия: сломался принтер в кабинете прямо перед совещанием. Workaround — отправить файлы на общий принтер в коридоре, чтобы хоть как-то распечатать документы. Постоянное решение — заменить перебитый кабель питания, чтобы принтер заработал окончательно.
Когда для ошибки найдено и внедрено постоянное решение, её запись должна быть либо архивирована, либо удалена из активной KEDB, потому что проблема больше не будет возникать.
Как KEDB работает на практике
Жизненный цикл записей в KEDB можно описать тремя основными сценариями.
- Создание записи. Когда инцидент решён временным способом (workaround), в KEDB создаётся новая запись. В ней фиксируются: описание инцидента, симптомы, что именно сделали для восстановления. Например, пользователь сообщает, что Microsoft Outlook вылетает при загрузке писем. Поддержка предлагает временно пользоваться веб-версией. Эта информация идёт в KEDB.
- Использование записи. Когда приходит новый инцидент, поддержка сначала проверяет KEDB. Если есть похожая запись, она сразу применяет известный workaround. Если workaround оказывается неточным или неполным, специалисты могут дополнить запись, улучшив базу знаний.
- Архивация записи. Если для известной ошибки позже находят постоянное решение (например, выяснили, что причина — конфликт с Bluetooth-расширением, отключили его на всех компьютерах), запись можно архивировать или удалить. Теперь она не нужна в активной базе, потому что инцидент больше не повторится.
Итог
KEDB — это не просто список ошибок, а инструмент, который превращает опыт прошлых сбоев в актив, ускоряющий будущие восстановления. Она помогает команде быстрее реагировать на инциденты, сокращает время простоя и даёт возможность сфокусироваться на поиске постоянных решений, а не на том, чтобы каждый раз гадать, с чего начать диагностику.