Хороший диагност это не призвание, а навык
В почти всех профессиях порою нужно быстро локализовать проблему и выдать план по её устранения. В ИТ это даже в целую субкультуру выродилось в конечном счете (привет SRE'шники). И не знаю откуда пошли ноги выростать, но бытует одна басня, что хороший диагност мол это дар с рождения, кому-то вот не дано понимать быстро в чем дело и т.д. Брехня, чушь и гнусная инсинуация. Умение быстро находить неисправность или детектировать поломку, или определять болезнь, или что-то другое можно натренировать. Более того медиков именно натаскивают в этом навыке. В ИТ же на этот навык просто болт забили и поэтому и есть те, кто быстро разбирается в проблемах и решает их и те, кто не понимает как это так получается быстро вникнуть в суть и задетектировать неисправность.
Частично в прошлых своих опусах я писал про важность широкого кругозора в разработке и почему фулстеки – крутые ребята. Вот и в диагностике тоже самое, чем больше багаж знаний и понимание как те или иные грабли бьют по лбу, тем вероятнее, что получится с пол пинка понять какой черенок торчит из задницы дворника с первого взгляда на кофейную гущу растворимого кофе из автомата с заправки.
В авиации есть такая процедура префлайт инспекшн. По сути это диагностика всех частей самолета на предмет их работы и нахождения в допусках. Сама эта процедура простая, есть чеклист идешь сверху вниз и если что не так – отправляешься на устранение, а только потом взлетаешь. Но создание этих чеклистов и простота диагностики стала возможна только благодаря тому, что пилот или техник, который проводит инспекцию до каждого болта знает как должно быть все закручено и как должно работать. В ИТ же проектах большинство разработчиков не знает как работает их проект, зачем он так работает, для чего этот кусок кода или эта кнопка и т.д. поэтому провести диагностику эффективно может не каждый. Эта первая проблема, которую надо стараться устранить для повышения скорости локализации проблемы.
Автомеханики, особенно хорошие мотористы, могут по звуку мотора часто приговорить конкретный его агрегат без дефектовки и глубокой диагностики потому, что имеют "наслушанность" и понимают фундаментальное строение двигателя. Но если даже самого лучшего моториста ф1 взять и заставить диагностировать реактивный двигатель с коими у него опыта не было – эффективности и точности будет ноль, хотя вероятно в общих чертах с этой задачей может и справится. В ИТ же очень много людей вообще не в курсе как работают фундаментальные процессы и как следствие не понимают вещей сложенных из простых в сложные и воспринимают комплексные штуки как самую малую часть пазла. Отсюда кстати имхо и растут ноги у каноничной практики "выключить и включить". В общем - это вторая фаза, которую нужно устранить для повышения скорости локализации проблем.
Многие ученые прежде чем смешать три пробирки в одну или выкинуть гирю из окна сидят с листочком и бумажкой и занимаются моделированием и расчетами предстоящих действий. Это позволяет им проводить работы над ошибками, повторять эксперименты, делиться знаниями и иметь фундаментальную базу принятия решений. В ИТ же часто многие вещи делаются "хрен знает почему это работает, но не трогай". Так происходит часто из-за первых двух пунктов вместе взятых, но еще и из-за того, что навыка моделирования решения в ИТ не очень прививают. Молодняку не объяснить важность, а опытные проводят эти действия в голове и на живую. Тому конечно еще потворствует необходимость постоянной экономии и диких сроков от бизнеса, но сути не меняет. Когда вы последний раз видели досконально проработанный план и архитектурную схему работы приложения в облаке? А документацию написанную до разработки фичи? Иногда мы с этим встречаемся, иногда нас заставляют работать через эти практики, но в общей массе - этого почти нет. И это третья проблема, решив которую мы приблизимся к ускорению диагностики проблемы и да она пересекается с первым пунктом ведь корень почти всего – это действительное знание как должно было быть.
Имея все три решенных проблемы, мы можем сделать три притопа два прихлопа и понять в чем дело: ⁃ Проводим внешнюю инспекцию проблемы ⁃ По полученным данным сверяемся, а как оно должно было быть ⁃ На основе фундаментальных познаний и знания о работе системы выносим заключения
Да, будет процент ошибок, но он будет стремиться к минимальному значению.