"Убить ламера" или системный подход к траблшутингу

Автор: Денис Теребий

Опубликовано 16 февраля 2010 года

Наш читатель Денис Теребий написал статью о различиях между ИТ-специалистами и ИТ-ламерами. А также о том, что вторые при желании вполне могут со временем стать первыми. Орфография и пунктуация автора сохранены.

Предисловие: Надеюсь, что для большинства читателей я данной статьёй ничего нового не открою. Но как показывает мой опыт ИТ-руководителя, для многих (практически всех) начинающих ИТ специалистов многие вещи очевидными не являются, что сильно снижает их эффективность. Для них и их руководителей эта статья.

Как отличить ИТ-специалиста от ИТ-ламера? Задумывались? Наверняка задумывались те, кому нужно было нанять сотрудника, и желательно - с мозгами. Как показывает практика, никакие сертификаты не покажут реальной способности сотрудника решать нетипичные задачи. Знания систем и способность эти знания успешно использовать в нештатных ситуациях - весьма не одно и тоже. Так где критерий?

А критерий не изменился со времен первых инженеров, строивших пирамиды.

Специалист воспринимает систему как комплекс связанных между собой элементов, знает механизмы и правила связей и в состоянии мысленно представить модель системы или отдельных её элементов. Пройтись мысленно же от базовых блоков до ожидаемых наблюдаемых эффектов и наоборот - по наблюдаемым эффектам вычислить нюансы работы базовых блоков.

Ламер же воспринимает систему как некий условный алтарь, перед которым он "камлает". Он знает некие наборы действий, которые должны приводить к определенным результатам. Почему именно такие наборы и именно такие результаты - обычно ламер знает плохо или не знает вовсе. При этом человек может быть крутосертифицированным специалистом, успешно устанавливать и настраивать достаточно сложные системы, и всё равно оставаться лишь хорошо натасканным ламером.

Специалист оперирует моделью. Ламер - набором шаблонов. Специалист в одной области может быстро разобраться в другой родственной, поняв основные принципы построения системы. Ламера нужно переучивать и долго натаскивать - тогда он кое как сможет выполнять те задачи, на которые его натаскали.

Вопрос первый - почему так происходит?

Чтобы ответить, придется обратить внимание на механизмы работы нашего мозга. Не углубляясь в детали обратим внимание лишь на базовые аспекты: когда мозг получает новую ситуацию, с которой ему нужно справиться, он в первую очередь обращается к воспоминаниям в поисках схожей ситуации. Если находит - то предлагает тот вариант решения, который сработал тогда. И этот алгоритм - основа мозговой деятельности любого земного организма с высшей нервной системой. В том числе и для высших приматов вплоть до нас с вами.

Иначе говоря, использование шаблонов при поиске решения - это штатный режим для человеческого сознания. Более того, в подавляющем большинстве вопросов, начиная с моторики, продолжая межполовыми вопросами и заканчивая управлением государством - чуть менее чем всюду используется именно эта схема. Потому как она - оптимальна с точки зрения затраты/эффективность в подавляющем большинстве случаев. К тому же ни один мозг не в состоянии моделировать в себе сколько либо значительную часть окружающей реальности.

Но в отдельных ограниченных областях мы можем выходить за пределы шаблонного восприятия, и именно в этих областях мы можем и должны быть специалистами. Такой выход не отменяет использование шаблонов, но значительно расширяет и дополняет их.

Собственно, вопрос второй - как?

Как убить в себе ламера в отдельно взятой области и стать в ней специалистом?

Ответ уже был дан - строить модели и оперировать ими.

Ниже будет дан простой сценарий по использованию моделей в траблшутинге. В текущем виде он относится к системному и сетевому администрированию, но, полагаю, при желании может быть расширен как на программирование, так и на далекие от ИТ области.

Уточняю - речь идет о проблеме, не являющейся хорошо известной столкнувшемуся с ней и к которой "стандартные драйвера не подошли"(с)

1. Первейшая задача траблшутинга - точная локализация проблемы. В зависимости от области и компетенции, успешная локализация означает от 50 до 95 процентов успешного разрешения проблемы.

2. Вы столкнулись с проблемой. Данная проблема имеет определенные проявления - нечто не работает или нечто работает не так как должно. Отлично - отметьте все проявления проблемы, которые можете. Т.е. то-то и то-то - не работает, это - работает вот так, а должно было этак. Ничего не меняйте.

3. Посмотрите на базовые показатели системы, постарайтесь отметить отклонения от нормальных или ожидаемых. Либо отметить полное соответствие - на данном этапе данная информация имеет совершенно идентичный уровень важности. Опять-же ничего не меняйте.

4. Остановитесь и подумайте. Теперь ваша задача - сформулировать предположение о том, некорректная работа в какой подсистеме (или подсистемах) могла привести к тому набору симптомов и показателей, которые вы зафиксировали. Данное предположение должно быть более-менее разумным и объяснять все наблюдаемые проявления. Данный пункт - самый важный.

5. Найдите способ проверить ложность вашего предположения. Это может быть счетчик или датчик, это может быть вариант пустить работу системы в обход подозреваемой подсистемы с редуцированием некого функционала, думайте. Главное, чтобы данный показатель мог гарантированно продемонстрировать ошибочность вашего предположения, если оно действительно ошибочно. Акцентирую - задача первичной проверки не доказать правильность предположения, а гарантированно отбросить предположение в случае его ошибочности.

6. Если критерий показал ошибочность предположения, восстанавливайте исходные настройки и возвращайтесь к пункту 3. Теперь у вас есть дополнительная информация о работе системы и это должно помочь в размышлениях.

7. Если в результате проверки предположение опровергнуто не было, ищите способ проверить верность и единственность проблемного места. Вполне возможно, что система не работает из-за комплекса некорректно работающих подсистем, причем отдельные некорректные подсистемы могут друг друга компенсировать. Если возможно - поставьте "заглушку" на подозреваемую подсистему и проверьте работу остальных элементов.

8. Последовательно увеличивая детализацию предположения, локализуйте проблему. А локализованная проблема - это практически решенная проблема. Её можно уже и исправить (если хватает компетенции), и погуглить (если не хватает), и найти способ обойти (если компетенции не хватает и у гугла).

Очень важно помнить один важный момент: работающая система и правильно работающая система - не обязательно одно и то же.

Работающая система решает текущие задачи, но как она будет себя вести при изменениях - неизвестно. Для срочного решения текущей проблемы это может быть приемлемо, но на сколько либо длительной перспективе такая система куда неприятнее, чем не работающая вовсе.

Правильно работающая система позволяет планировать изменения и вносить их с ожидаемым итоговым поведением. В ней исключена ситуация, когда исправление ошибки в одном месте системы приводит к нарушению в другом, потому как до сих пор они друг друга успешно компенсировали.

Удачи всем в отстреле проблем.