В последнее время стал больше замечать, что люди не могут сами найти нужную информацию. Вместо того, чтобы искать ее, они начинают спрашивать в общих чатах или кого-либо напрямую. В большинстве случаев, это дополнительно отвлекает от работы и, как результат, какая-либо задача просто блокируется до времени, когда кто-то не поможет автору или укажет куда нужно смотреть. Я довольно давно выделил для себя шаги, которые помогают мне получать нужную информацию. Меня часто удивляет, что большинство этим не пользуется.
Для примера, возьмем абстрактного DevOps. Его задача — разобраться в том, что какой-то сервер не работает. Часто вижу, что вместо того, чтобы пытаться найти нужную информацию самостоятельно, он спрашивает ее у других людей. Или еще хуже, в случае, если члены команды находятся в разных часовых зонах (10 часов разницы, например), то девопс просто ждет, когда же проснется человек, который, по его мнению, знает ответы на его вопросы. И ведь всего этого можно было бы избежать, если бы девопс просто знал, где нужно искать:
Все описанное выше стоит начинать, когда вы не нашли нужных вам данных в вашей внутренней wiki. И это даже не исчерпывающий список. Если же и вышеописанные действия не дали вам достаточно информации, то тут уже стоит эскалировать вопрос ко всей команде или тим/тех лиду. И, конечно, не забудьте записать всю добытую вами информацию в wiki, что бы другой человек уже не тратил времени на поиск.
Для примера, возьмем абстрактного DevOps. Его задача — разобраться в том, что какой-то сервер не работает. Часто вижу, что вместо того, чтобы пытаться найти нужную информацию самостоятельно, он спрашивает ее у других людей. Или еще хуже, в случае, если члены команды находятся в разных часовых зонах (10 часов разницы, например), то девопс просто ждет, когда же проснется человек, который, по его мнению, знает ответы на его вопросы. И ведь всего этого можно было бы избежать, если бы девопс просто знал, где нужно искать:
- Jira или другая трекинг система: поиск тикета по ip сервера, имени сервера или имени приложения. В общем, поиск по любой знакомой уникальной информации о целевой системе. В комментариях к тикетам люди описывают что они делали, почему и где. Jira — это не только система, где помечается сколько поинтов займет задача и указывается кто ее будет делать, это также огромный кладезь информации о разных системах, описание прошлых проблем и, самое главное, того, что было сделано. А если вам повезет, то может и технические детали вы там тоже найдете. В большинстве случаев этой информации будет достаточно нашему девопсу, чтобы решить поставленную проблему.
- Если же в Jira ничего не нашлось, то стоить поискать в Slack или другом мессенджере, который использует ваша команда. Выберите наиболее подходящий канал, где возможно обсуждался ваш целевой сервер и начните опять искать по ключевой уникальной информации. Используйте разные варианты написания: ip через тире, доменное имя, короткое доменное имя, неофициальное имя сервера или даже по названию проекта и приложения. Если в Jira тикетах не достаточно информации о том, что было сделано, то стоит поискать и по имени тикета. Хоть мессенджеры и не самое лучше место для хранения подробностей, люди все равно оставляют информацию только там и не переносят ее в тикеты. Я видел огромные треды в Slack, в которых было уйма инфы о задаче, включая технические детали и обсуждения, почему было сделано так-то и абсолютно пустые тикеты в Jira.
- Ну как же мы можем забыть про email. Уже давно это является одним из основных средств коммуникаций. Массовые рассылки, уведомления, нити обсуждения — все это может содержать именно ту информацию, которая вам нужна.
- Jell и другие Scrum системы. Люди пишут там то, что они будут делать или уже сделали. Не редко там есть и какие-то минимальные данные о задачах и принятых решениях. Возможно, вам повезет и вы найдет то, что вам нужно. Если же нет, то найдете человека, который делал что-то раньше по вашей задаче или системе.
- Сейчас уже все стараются перейти на описание изменений системы в коде. Конечно, в разработке приложения это происходит по умолчанию, но вот у девопс это стало стандартом не так давно.
Ищите нужный вам репозиторий и уже в нем ищете ваш сервер/систему по ключевым данным (ip, domain and etc). По гиту смотрите историю изменений и обязательно просматривайте комментарии и привязанные к ним задачи.
- Если же целевой системы не нашлось в репозиториях, то стоит поискать в системах обработки логов. Узнайте, где в вашей фирме хранят логи. Посмотрите по ним, что же происходило с системой и кто туда заходил в последнее время (Не редко бывает, что тот, кто зашел последний, все и сломал, чиня что-то другое). Если же вы имеете логи событий, произошедших в вашей инфраструктуре (такие как AWS CloudTrail), то они станут вам очень полезным помощником в поиске и устранении проблем.
- Если вам нужны пароли от систем или у вас есть централизованное хранилище паролей, то стоит искать по различных ключевым фразам везде, а не только в отдельной группе хранилища.
То есть, если у вас есть разделение паролей/секретов по группам, например, отдельные группы по названиями проектов, то не останавливайте ваш поиск только по одной группе, где по логике должна быть ваша система. Ошибаются все, и может быть кто-либо сохранил пароль от вашей целевой системы не в правильной группе или под очень странны названием.
Вот почему стоит пробовать искать по различным ключевым фразам и быть тут очень гибким.
- Возможно у вас в фирме есть реализованная система управления изменениями. Это значит, что все изменения в определенных системах описаны и проходят процесс одобрения и тестирования. Тут для нас главное то, что они «описаны». Смело пробуйте там искать по вашим ключевым данным.
- Если у вас есть система, которая агрегирует проблемы, то стоит посмотреть и там. Может оказаться, что ваша система не работает из-за проблемы в других системах, например, в файрволе. Зная это, вы не будет тратить время на исследование и сразу свяжетесь с людьми, которые устранят проблему выше.
- Организация сети — довольно сложная и нетривиальная задача. Для того, чтобы как-то упорядочить изменения в настройках файрволов и других сетевых устройствах, там часто
есть история изменений с комментариями. Если вы полагаете, что ваша проблема связана с сетевым соединением, то стоит посмотреть историю изменения файрволов, начиная с времени, когда ваша проблема появилась.
- Jenkins и другие CI/CD системы так же имеют историю изменений для нужных вам jenkins jobs. Стоит самостоятельно там поискать, а не спрашивать у всей команды — не меняли ли они что-то в CI/CD за последнее время и не говоря подробностей о том, что вы ищете :)
- Если у вас есть общее для всей компании файлохранилище, то попробуйте поискать и там. Скорее всего поиск будет только по названию документов, поэтому используйте в поиске название проекта, репозитория, приложения или еще чего-то, что можно быть в названии.
Все описанное выше стоит начинать, когда вы не нашли нужных вам данных в вашей внутренней wiki. И это даже не исчерпывающий список. Если же и вышеописанные действия не дали вам достаточно информации, то тут уже стоит эскалировать вопрос ко всей команде или тим/тех лиду. И, конечно, не забудьте записать всю добытую вами информацию в wiki, что бы другой человек уже не тратил времени на поиск.