Как стать профессиональным IT-коллекционером? Часть 3. Ищем баги
В предыдущих частях («Начало», «Врываемся в DevOps») я рассказывала о том, как опыт работы в команде сопровождения GlowByte быстро принес мне базовые знания Unix, работы с БД и SQL и навыки DevOps. В этой части я расскажу про траблшутинг, как я научилась анализировать массивные логи и следить за множеством метрик «здоровья» системы. Эта часть наиболее верно описывает то, что ожидают компании от технического инженера службы поддержки.
Логи
Я научилась искать нужное и важное в бесконечных потоках логов и мониторинг-показателях. Но это случилось не сразу. В самом начале было долго, непонятно, болезненно искать ошибку в файле на несколько гигабайт с кучей полезной и бесполезной информации. Бесило все: открытие этих логов в файловых редакторах, попытки поиска, чтение однотипной информации, которая сливалась в сплошную пасту, — хотелось уснуть. Меня угнетало, что другие коллеги делали все быстро, за несколько минут находили ошибку в логе, еще за несколько — место в коде, которое вызвало ее. Они разбирались в том, что читали в логе, в то время как я могла поставить себе единицу из 10 по всем этим пунктам. Пока мои коллеги делали все, что нужно, я только открывала лог и скроллила его мелкими итерациями.
Потом я прокачала навыки в Linux (о чем рассказала в предыдущей статье), и просмотр логов оказался не такой уж скучной и пресной задачей. Я увеличила свою скорость поиска по логам в 7–8 раз, стала открывать их без зависающих редакторов, научилась корректно выбирать ключевые слова, быстро искать и перескакивать в нужные места лога.
Главный секрет успешности заключался в самом простом — наблюдении. Я была внимательной на онлайн-митингах с расшаренным экраном коллег или заказчика и запоминала, что они делают, анализировала, почему они быстрые, а я такая медленная. Еще помогал просмотр вывода history на серверах: я смотрела флаги к командам, которые выполняли другие, и читала про каждый, выписывая полезные. На этом начала формироваться моя база знаний (о ней детально расскажу в следующих статьях): мне казалось, что если я не запишу, то непременно забуду все и потом потрачу много времени на повторный поиск.
Траблшутинг
Ошибка — явление уникальное. Не получится причесать все ситуации под одну гребенку и по памяти ответить, что вызвало ошибку в конкретном случае, как ее исправить «по инструкции». IMHO, невозможно написать единое пособие/ словарь формата «Ошибка-решение». Часто одна и та же ошибка может возникать по разным причинам. Бывает так, что одну ошибку вызывает сразу несколько проблем. А бывает так, что одна проблема тянет другую, и специалисту поддержки нужно распутать весь клубок. Это почти всегда частные случаи, которые нужно анализировать и решать по-разному.
Пример из моей практики в GlowByte: пользователи некой компании, которую мы сопровождали, повысили нагрузку на систему от бизнес-сценариев в определенные дни и забили все место на диске, а некоторое Java-приложение, работающее с этим файловым хранилищем, выдало ошибку и не выполнило свою целевую функцию — не записало в БД данные в таблицу. В итоге пользователь сформулировал проблему следующим образом: «В таблице в БД я не вижу данных».
Чтобы понять причины, из-за которых все остановилось, нужно было проделать немалую работу по исследованию всей цепочки, по которой эти данные шли. Здесь важно было знать логическую архитектуру решения и быть знакомым с бизнес-требованиями к системе, с техническими заданиями, руководствами пользователей и администраторов. Нужно было понимать, что может и не может сделать конкретный пользователь, быть в курсе регламентных процессов в системе.
Помимо этого, всегда важно укладываться в SLA, ведь пользователь ждет быстрого решения, а ряд кейсов имеет критический бизнес-приоритет. Специалисту сопровождения постоянно нужно выдвигать гипотезы, проверять их и отвергать неоправданные. Часто одна гипотеза порождает другую, а та, в свою очередь, следующую. Нужно не запутаться в своих гипотезах, держать их в порядке и не проверять то, что уже проверено.
При самых сложных кейсах возникают ситуации, когда все лучшие умы собираются на встрече и коллективно выдвигают свои теории, рассуждают. У каждого накоплен свой неповторимый опыт нахождения ошибок. Мозговой штурм — отличный способ решить проблему.
В общем, это все увлекательно и интересно. Работая в службе поддержки 3-й линии, можно почувствовать себя исследователем, который врывается в неизвестность и ищет истину среди множества фактов, проверок, неочевидных и запутанных вещей. Поддержка — это не про чтение скучных логов и однотипные правки. Поддержка — про исследование, неординарность и запутанность.
