зажиточных, о чём нам подробно рассказал Аристотель. И те надежды, которые в Перестройку возлагали на народоправство, да и возлагают посейчас, говорят не о том, что большевики скрывали Отца философии от масс, а о том, что его элементарно ленятся читать…
Но и говорить, как любят часто, что нам не повезло с народом, нельзя. В обрушении здания всегда виноват архитектор. Другое дело, что из самана строят по иным канонам, чем из портланд-бетона и нержавеющей стали. И претендующие на право строить общество обязаны это знать.
"Убить ламера" или системный подход к траблшутингу
Автор: Денис Теребий
Предисловие: Надеюсь, что для большинства читателей я данной статьёй ничего нового не открою. Но как показывает мой опыт ИТ-руководителя, для многих (практически всех) начинающих ИТ специалистов многие вещи очевидными не являются, что сильно снижает их эффективность. Для них и их руководителей эта статья.
Как отличить ИТ-специалиста от ИТ-ламера? Задумывались? Наверняка задумывались те, кому нужно было нанять сотрудника, и желательно - с мозгами. Как показывает практика, никакие сертификаты не покажут реальной способности сотрудника решать нетипичные задачи. Знания систем и способность эти знания успешно использовать в нештатных ситуациях - весьма не одно и тоже. Так где критерий?
А критерий не изменился со времен первых инженеров, строивших пирамиды.
Специалист воспринимает систему как комплекс связанных между собой элементов, знает механизмы и правила связей и в состоянии мысленно представить модель системы или отдельных её элементов. Пройтись мысленно же от базовых блоков до ожидаемых наблюдаемых эффектов и наоборот - по наблюдаемым эффектам вычислить нюансы работы базовых блоков.
Ламер же воспринимает систему как некий условный алтарь, перед которым он 'камлает'. Он знает некие наборы действий, которые должны приводить к определенным результатам. Почему именно такие наборы и именно такие результаты - обычно ламер знает плохо или не знает вовсе. При этом человек может быть крутосертифицированным специалистом, успешно устанавливать и настраивать достаточно сложные системы, и всё равно оставаться лишь хорошо натасканным ламером.
Специалист оперирует моделью. Ламер - набором шаблонов. Специалист в одной области может быстро разобраться в другой родственной, поняв основные принципы построения системы. Ламера нужно переучивать и долго натаскивать - тогда он кое как сможет выполнять те задачи, на которые его натаскали.
Вопрос первый - почему так происходит?
Чтобы ответить, придется обратить внимание на механизмы работы нашего мозга. Не углубляясь в детали обратим внимание лишь на базовые аспекты: когда мозг получает новую ситуацию, с которой ему нужно справиться, он в первую очередь обращается к воспоминаниям в поисках схожей ситуации. Если находит - то предлагает тот вариант решения, который сработал тогда. И этот алгоритм - основа мозговой деятельности любого земного организма с высшей нервной системой. В том числе и для высших приматов вплоть до нас с вами.
Иначе говоря, использование шаблонов при поиске решения - это штатный режим для человеческого сознания. Более того, в подавляющем большинстве вопросов, начиная с моторики, продолжая межполовыми вопросами и заканчивая управлением государством - чуть менее чем всюду используется именно эта схема. Потому как она - оптимальна с точки зрения затраты/эффективность в подавляющем большинстве случаев. К тому же ни один мозг не в состоянии моделировать в себе сколько либо значительную часть окружающей реальности.
Но в отдельных ограниченных областях мы можем выходить за пределы шаблонного восприятия, и именно в этих областях мы можем и должны быть специалистами. Такой выход не отменяет использование шаблонов, но значительно расширяет и дополняет их.
Собственно, вопрос второй - как?
Как убить в себе ламера в отдельно взятой области и стать в ней специалистом?
Ответ уже был дан - строить модели и оперировать ими.
Ниже будет дан простой сценарий по использованию моделей в траблшутинге. В текущем виде он относится к системному и сетевому администрированию, но, полагаю, при желании может быть расширен как на программирование, так и на далекие от ИТ области.
Уточняю - речь идет о проблеме, не являющейся хорошо известной столкнувшемуся с ней и к которой 'стандартные драйвера не подошли'(с)
1. Первейшая задача траблшутинга - точная локализация проблемы. В зависимости от области и компетенции, успешная локализация означает от 50 до 95 процентов успешного разрешения проблемы.
2. Вы столкнулись с проблемой. Данная проблема имеет определенные проявления - нечто не работает или нечто работает не так как должно. Отлично - отметьте все проявления проблемы, которые можете. Т.е. то-то и то-то - не работает, это - работает вот так, а должно было этак. Ничего не меняйте.
3. Посмотрите на базовые показатели системы, постарайтесь отметить отклонения от нормальных или ожидаемых. Либо отметить полное соответствие - на данном этапе данная информация имеет совершенно идентичный уровень важности. Опять-же ничего не меняйте.
4. Остановитесь и подумайте. Теперь ваша задача - сформулировать предположение о том, некорректная работа в какой подсистеме (или подсистемах) могла привести к тому набору симптомов и показателей, которые вы зафиксировали. Данное предположение должно быть более-менее разумным и объяснять все наблюдаемые проявления. Данный пункт - самый важный.
5. Найдите способ проверить ложность вашего предположения. Это может быть счетчик или датчик, это может быть вариант пустить работу системы в обход подозреваемой подсистемы с редуцированием некого функционала, думайте. Главное, чтобы данный показатель мог гарантированно продемонстрировать ошибочность вашего предположения, если оно действительно ошибочно. Акцентирую - задача первичной проверки не доказать правильность предположения, а гарантированно отбросить предположение в случае его ошибочности.
6. Если критерий показал ошибочность предположения, восстанавливайте исходные настройки и возвращайтесь к пункту 3. Теперь у вас есть дополнительная информация о работе системы и это должно помочь в размышлениях.
7. Если в результате проверки предположение опровергнуто не было, ищите способ проверить верность и единственность проблемного места. Вполне возможно, что система не работает из-за комплекса некорректно работающих подсистем, причем отдельные некорректные подсистемы могут друг друга компенсировать. Если возможно - поставьте 'заглушку' на подозреваемую подсистему и проверьте работу остальных элементов.
8. Последовательно увеличивая детализацию предположения, локализуйте проблему. А локализованная проблема - это практически решенная проблема. Её можно уже и исправить (если хватает компетенции), и погуглить (если не хватает), и найти способ обойти (если компетенции не хватает и у гугла).
Очень важно помнить один важный момент: работающая система и правильно работающая система - не обязательно одно и то же.
Работающая система решает текущие задачи, но как она будет себя вести при изменениях - неизвестно. Для срочного решения текущей проблемы это может быть приемлемо, но на сколько либо длительной перспективе такая система куда неприятнее, чем не работающая вовсе.
