3 причини защо коренните причини на инцидентите се установяват с голямо забавяне.
Не проверяваме за скоро направени промени
Нека да видим един прост пример. Имам VPN от домашния рутър до офиса ми. Имах спешна работа и VPNът не работеше. Нямах интернет услуга. Обадих се на съпорта и им обясних, че имат проблем в мрежата, тъй като виждах една машина в мрежата им и нищо друго в интернет. Те отговориха, че няма никакви проблеми при тях. Бях много ядосана докато не се сетих за малка промяна в конфигурацията по-рано вечерта. Тази промяна беше причинила прекъсването, но моята арогантност не ми позволи да помисля първо за възможни промени, които някой от семейството може да е направил.
Не познаваме архитектурата на прекъсналата услуга
Потребителите срещат проблем и пускат инцидент. Отговорност на инженера е да разбере за всички симптоми и да ги види в контекста на архитектурата на услугата, на всички технологични компоненти, от които зависи. Често съпортът има идея какво може да причинява инцидентите и директно да посочи проблемния компонент. Тази интуиция е резултат на опит (както индивидуален, така и знание на компанията като цяло). Това може драстично да скъси времето за диагностика. Ето защо всички ние искаме да посетим най-добрият лекар и да отидем в най-добрата клиника, когато имаме медицински проблем. Но все пак не всички хора с оплаквания имат настинка. Някои страдат от сложни и редки болести и се нуждаят от систематичен подход.
Изглежда интуитивно, че трябва да изследваме всички компоненти по реда на вероятността да причиняват симптомите или в зависимост от времето, което е нужно за да докажеш хипотезата, или в комбинация. Вместо това инженерите, а често и лекарите, се фокусират върху елементите, с които имат най-голям опит и се опитват да вкарат проблема в тази област. Неразбирането на услугата от край до край води до дълги часове или дни без да знаем от каква болест страдаме. Или безкрайно да разчитаме на лекарства, които намаляват болката, но не ни лекуват.
Клиент използва услуга за данни и наблюдава голяма загуба на пакети. След пълен преглед на рутърите, които съставят решението моите колеги не успяха да намерят проблема. Накрая се оказа проблем в кабел. Кабелите са фундаменталните елементи, които ние приемаме за даденост и изключваме от диагностиката.
Втурваме се да действаме вместо да следваме структуриран подход
Тази грешка обикновено е следствие на нашата арогантност за това, че познаваме нашата система толкова добре, че можем да прескочим по-простите неща и да се заемем веднага с най-сложните елементи. Започваме да действаме без отлагане и да променяме системата. По този начин бързо правим невалидни оригиналните симптоми, които сме разбрали от клиента. Ако за първи път системата има такова поведение е много вероятно инженерът изобщо да не разбере коренната причина. Промяната на параметрите без ясна идея как това може да промени услугата е стреляне в тъмното и не е начинът, по който искаме бизнесът да бъде управляван. Много по-добра идея е да следваме модела на доктор Хаус – заедно с екипа си идентифицира всички симптоми, генерират хипотези за болестите, които е вероятно да ги причиняват, записват списъка с болести на флипчарта по реда на тяхната вероятност и търсят начин да докажат коренната причина в този ред.
Една компания имаше проблем да достъпва ресурси в интернет. Използваха виртуален файъруол, който показваше ненормално поведение. Инженерите увеличиха ресурсите на файъруола и след това направиха ъпгрейд към следващата версия. Промениха и конфигурацията на главния рутър. В този момент намирането на коренната причина изискваше връщане на всички промени и включване на тестове на всяка стъпка. В крайна сметка се оказа, че проблемът не в нито един от компонентите, а е атака, която натоварва извънредно интернет връзката.
Нина е високо-квалифициран консултант и лидер с повече от 20 години опит във воденето на сложни проекти и трансформации. Тя е добре познато име в областта на Agile, бизнес анализ, архитектура и управлението на процеси.
