Логи
Я научилась искать нужное и важное в бесконечных потоках логов и мониторинг-показателях. Но это случилось не сразу. В самом начале было долго, непонятно, болезненно искать ошибку в файле на несколько гигабайт с кучей полезной и бесполезной информации. Бесило все: открытие этих логов в файловых редакторах, попытки поиска, чтение однотипной информации, которая сливалась в сплошную пасту, – хотелось уснуть. Меня угнетало, что другие коллеги делали все быстро, за несколько минут находили ошибку в логе, еще за несколько – место в коде, которое вызвало ее. Они разбирались в том, что читали в логе, в то время как я могла поставить себе единицу из 10 по всем этим пунктам. Пока мои коллеги делали все, что нужно, я только открывала лог и скроллила его мелкими итерациями.
Потом я прокачала навыки в Linux (о чем рассказала в предыдущей статье), и просмотр логов оказался не такой уж скучной и пресной задачей. Я увеличила свою скорость поиска по логам в 7-8 раз, стала открывать их без зависающих редакторов, научилась корректно выбирать ключевые слова, быстро искать и перескакивать в нужные места лога.
Главный секрет успешности заключался в самом простом – наблюдении. Я была внимательной на онлайн-митингах с расшаренным экраном коллег или заказчика и запоминала, что они делают, анализировала, почему они быстрые, а я такая медленная. Еще помогал просмотр вывода history на серверах: я смотрела флаги к командам, которые выполняли другие, и читала про каждый, выписывая полезные. На этом начала формироваться моя база знаний (о ней детально расскажу в следующих статьях): мне казалось, что если я не запишу, то непременно забуду все и потом потрачу много времени на повторный поиск.
Траблшутинг
Ошибка – явление уникальное. Не получится причесать все ситуации под одну гребенку и по памяти ответить, что вызвало ошибку в конкретном случае, как ее исправить “по инструкции”. IMHO, невозможно написать единое пособие/ словарь формата “Ошибка-решение”. Часто одна и та же ошибка может возникать по разным причинам. Бывает так, что одну ошибку вызывает сразу несколько проблем. А бывает так, что одна проблема тянет другую, и специалисту поддержки нужно распутать весь клубок. Это почти всегда частные случаи, которые нужно анализировать и решать по-разному.
Пример из моей практики в GlowByte: пользователи некой компании, которую мы сопровождали, повысили нагрузку на систему от бизнес-сценариев в определенные дни и забили все место на диске, а некоторое Java-приложение, работающее с этим файловым хранилищем, выдало ошибку и не выполнило свою целевую функцию – не записало в БД данные в таблицу. В итоге пользователь сформулировал проблему следующим образом: “В таблице в БД я не вижу данных”.
Чтобы понять причины, из-за которых все остановилось, нужно было проделать немалую работу по исследованию всей цепочки, по которой эти данные шли. Здесь важно было знать логическую архитектуру решения и быть знакомым с бизнес-требованиями к системе, с техническими заданиями, руководствами пользователей и администраторов. Нужно было понимать, что может и не может сделать конкретный пользователь, быть в курсе регламентных процессов в системе.