Как стать автором
Обновить
55.92

Как стать профессиональным IT-коллекционером? Часть 3. Ищем баги

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров1.3K

В предыдущих частях (“Начало”, “Врываемся в DevOps”) я рассказывала о том, как опыт работы в команде сопровождения GlowByte быстро принес мне базовые знания Unix, работы с БД и SQL и навыки DevOps. В этой части я расскажу про траблшутинг, как я научилась анализировать массивные логи и следить за множеством метрик “здоровья” системы. Эта часть наиболее верно описывает то, что ожидают компании от технического инженера службы поддержки.

Логи

Я научилась искать нужное и важное в бесконечных потоках логов и мониторинг-показателях. Но это случилось не сразу. В самом начале было долго, непонятно, болезненно искать ошибку в файле на несколько гигабайт с кучей полезной и бесполезной информации. Бесило все: открытие этих логов в файловых редакторах, попытки поиска, чтение однотипной информации, которая сливалась в сплошную пасту, – хотелось уснуть. Меня угнетало, что другие коллеги делали все быстро, за несколько минут находили ошибку в логе, еще за несколько – место в коде, которое вызвало ее. Они разбирались в том, что читали в логе, в то время как я могла поставить себе единицу из 10 по всем этим пунктам. Пока мои коллеги делали все, что нужно, я только открывала лог и скроллила его мелкими итерациями. 

Потом я прокачала навыки в Linux (о чем рассказала в предыдущей статье), и просмотр логов оказался не такой уж скучной и пресной задачей. Я увеличила свою скорость поиска по логам в 7-8 раз, стала открывать их без зависающих редакторов, научилась корректно выбирать ключевые слова, быстро искать и перескакивать в нужные места лога. 

Главный секрет успешности заключался в самом простом – наблюдении. Я была внимательной на онлайн-митингах с расшаренным экраном коллег или заказчика и запоминала, что они делают, анализировала, почему они быстрые, а я такая медленная. Еще помогал просмотр вывода history на серверах: я смотрела флаги к командам, которые выполняли другие, и читала про каждый, выписывая полезные. На этом начала формироваться моя база знаний (о ней детально расскажу в следующих статьях): мне казалось, что если я не запишу, то непременно забуду все и потом потрачу много времени на повторный поиск.

Траблшутинг 

Ошибка – явление уникальное. Не получится причесать все ситуации под одну гребенку и по памяти ответить, что вызвало ошибку в конкретном случае, как ее исправить “по инструкции”. IMHO, невозможно написать единое пособие/ словарь формата “Ошибка-решение”. Часто одна и та же ошибка может возникать по разным причинам. Бывает так, что одну ошибку вызывает сразу несколько проблем. А бывает так, что одна проблема тянет другую, и специалисту поддержки нужно распутать весь клубок. Это почти всегда частные случаи, которые нужно анализировать и решать по-разному.

Пример из моей практики в GlowByte: пользователи некой компании, которую мы сопровождали, повысили нагрузку на систему от бизнес-сценариев в определенные дни и забили все место на диске, а некоторое Java-приложение, работающее с этим файловым хранилищем, выдало ошибку и не выполнило свою целевую функцию – не записало в БД данные в таблицу. В итоге пользователь сформулировал проблему следующим образом: “В таблице в БД я не вижу данных”. 

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

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

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

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

Теги:
Хабы:
Всего голосов 18: ↑17 и ↓1+16
Комментарии0

Публикации

Информация

Сайт
glowbyteconsulting.com
Дата регистрации
Дата основания
2004
Численность
1 001–5 000 человек
Местоположение
Россия
Представитель
Снежана Шибаева