В последнее время я все чаще замечаю, что люди не могут найти нужную им информацию самостоятельно.
Вместо того, чтобы ее искать, они начинают спрашивать в общих чатах или у кого-то напрямую.
В большинстве случаев это дополнительно отвлекает от работы и в результате любое задание просто блокируется, пока кто-нибудь не поможет автору или не укажет, где искать.
Довольно давно я определил для себя шаги, которые помогут мне получить нужную мне информацию.
Я часто удивляюсь, что большинство людей этим не пользуются.
Например, возьмем абстрактный DevOps. Его задача — выяснить, что какой-то сервер не работает. Я часто вижу, что вместо того, чтобы попытаться найти нужную ему информацию самостоятельно, он спрашивает ее у других людей.
Или ещё хуже, если члены команды находятся в разных часовых поясах (разница в 10 часов, например), то девопс просто ждёт, когда проснётся человек, который, по его мнению, знает ответы на его вопросы.
И всего этого можно было бы избежать, если бы девопсы просто знали, где искать:
- Jira или другая система отслеживания: поиск заявки по IP-адресу сервера, имени сервера или названию приложения.
В общем, ищите любую знакомую уникальную информацию о целевой системе.
В комментариях к билетам люди описывают, что они делали, почему и где.
Jira — это не только система, где отмечено, сколько баллов займет задача и кто ее будет делать, это еще и огромный кладезь информации о разных системах, описания прошлых проблем и, самое главное, того, что было сделано.
А если вам повезет, то, возможно, вы найдете там и технические подробности.
В большинстве случаев этой информации будет достаточно нашей команде разработчиков для решения проблемы.
- Если вы ничего не нашли в Jira, то стоит поискать в Slack или другом мессенджере, который использует ваша команда.
Выберите наиболее подходящий канал, где мог обсуждаться ваш целевой сервер, и снова начните поиск ключевой уникальной информации.
Используйте разные варианты написания: ip с тире, имя домена, короткое имя домена, неофициальное имя сервера или даже имя проекта и приложения.
Если в тикетах Jira недостаточно информации о том, что было сделано, то стоит поискать по названию тикета.
Хотя мессенджеры — не лучшее место для хранения реквизитов, люди все равно оставляют информацию только там, а не переносят ее в заявки.
Я видел огромные темы на Slack с массой информации о проблеме, включая технические детали и обсуждения того, почему это было сделано, и совершенно пустые заявки в Jira.
- Ну как можно забыть об электронной почте.
Издавна это было одним из основных средств связи.
Массовые рассылки, уведомления, темы обсуждений – все это может содержать именно ту информацию, которая вам нужна.
- Jell и другие Scrum-системы.
Люди пишут там, что они сделают или уже сделали.
Нередко имеются минимальные данные о поставленных задачах и принятых решениях.
Возможно, вам повезет и вы найдете то, что вам нужно.
Если нет, то найдите человека, который раньше что-то делал с вашей задачей или системой.
- Сейчас все пытаются перейти к описанию системных изменений в коде.
Конечно, при разработке приложений это происходит по умолчанию, но в девопсе это стало стандартом не так давно.
Ищите нужный вам репозиторий и уже в нем ищите свой сервер/систему по ключевым данным (ip, домен и т.д.).
Для Git посмотрите историю изменений и обязательно просмотрите комментарии и задачи, связанные с ними.
- Если целевая система не найдена в репозиториях, то стоит поискать в системах обработки логов.
Узнайте, где ваша компания хранит журналы.
Посмотрите на них, чтобы узнать, что случилось с системой и кто заходил в последнее время (Часто бывает, что тот, кто заходил последним, всё сломал, одновременно чиня что-то другое).
Если у вас есть журналы событий, произошедших в вашей инфраструктуре (например, AWS CloudTrail), то они станут очень полезным помощником в устранении неполадок.
- Если вам нужны системные пароли или у вас есть централизованное хранилище паролей, стоит искать разные ключевые фразы повсюду, а не только в конкретной группе репозиториев.
То есть если у вас есть разделение паролей/секретов на группы, например отдельные группы по названиям проектов, то не останавливайте поиск только на одной группе, где по логике должна находиться ваша система.
Все совершают ошибки, и, возможно, кто-то сохранил пароль для вашей целевой системы не в той группе или под очень странным именем.
Вот почему стоит попробовать искать разные ключевые фразы и проявлять здесь большую гибкость.
- Возможно, в вашей компании внедрена система управления изменениями.
Это означает, что все изменения в определенных системах описываются и проходят процесс утверждения и тестирования.
Для нас здесь главное то, что они «описаны».
Не стесняйтесь попробовать выполнить поиск там, используя ваши ключевые данные.
- Если у вас есть система, агрегирующая проблемы, то туда тоже стоит заглянуть.
Возможно, ваша система не работает из-за проблемы в других системах, например, в брандмауэре.
Зная это, вы не будете тратить время на исследования и сразу обратитесь к людям, которые устранят вышеописанную проблему.
- Организация сети – довольно сложная и нетривиальная задача.
Чтобы как-то организовать изменения в настройках межсетевых экранов и других сетевых устройств, часто приходится Есть история изменений с комментариями.
Если вы считаете, что ваша проблема связана с вашим сетевым подключением, то стоит просмотреть историю изменений брандмауэра, начиная с момента возникновения вашей проблемы.
- Jenkins и другие системы CI/CD также имеют историю изменений для необходимых вам заданий Jenkins. Стоит поискать там самому, а не спрашивать всю команду, менялось ли что-нибудь в CI/CD за последнее время, не рассказывая подробностей того, что вы ищете :)
- Если у вас есть файловое хранилище, общее для всей компании, попробуйте поискать и там.
Скорее всего, поиск будет только по названиям документов, поэтому используйте в поиске название проекта, репозитория, приложения или чего-нибудь еще, что может быть в заголовке.
И это даже не исчерпывающий список.
Если описанные выше шаги не дали вам достаточно информации, стоит передать проблему всей команде или руководителю команды/техническому руководителю.
И, конечно же, не забудьте записать всю полученную информацию в вики, чтобы другой человек не тратил время на поиски.
Теги: #Управление разработкой #Управление проектами #Читальный зал #Удаленная работа #удаленная #работа #коммуникации #эффективность работы #эффективность #продуктивность #ГТД #личный опыт #лайфхак
-
Microsoft Разрабатывает Онлайн-Версию Excel
19 Oct, 24 -
Linux – Как Альтернатива Windows
19 Oct, 24 -
Отношение К Безопасности Здесь И Там
19 Oct, 24 -
Попытка Побега
19 Oct, 24 -
Ваш Личный Dns — Еще Немного О Dns-Хостинге
19 Oct, 24 -
Письмо Разработчикам Mozilla Firefox (Юмор)
19 Oct, 24
