Эффективный поиск информации в работе

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

    Для примера, возьмем абстрактного DevOps. Его задача — разобраться в том, что какой-то сервер не работает. Часто вижу, что вместо того, чтобы пытаться найти нужную информацию самостоятельно, он спрашивает ее у других людей. Или еще хуже, в случае, если члены команды находятся в разных часовых зонах (10 часов разницы, например), то девопс просто ждет, когда же проснется человек, который, по его мнению, знает ответы на его вопросы. И ведь всего этого можно было бы избежать, если бы девопс просто знал, где нужно искать:

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

    Все описанное выше стоит начинать, когда вы не нашли нужных вам данных в вашей внутренней wiki. И это даже не исчерпывающий список. Если же и вышеописанные действия не дали вам достаточно информации, то тут уже стоит эскалировать вопрос ко всей команде или тим/тех лиду. И, конечно, не забудьте записать всю добытую вами информацию в wiki, что бы другой человек уже не тратил времени на поиск.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 9

      0
      Плохо, что внутренние вики как-то не до конца взлетели. Confluence у всех есть, а управление знаниями с помощью хотя бы Confluence почти ни у кого нет.
        0
        Ага, это обычная ситуация, что продукт купили, а как им правильно пользоваться люди не знают.
          0
          Думаю, просто Atlassian не заморачивается с продвижением этой функции. А сам-то рыться и ковыряться кто будет? Тестировал недавно пару новых плагинов для Jira — так там Wiki силами самой системы сделана абсолютно удобно.
          0
          moved
            0
            Как ни странно, у многих людей есть проблемы с поиском информации. Обычно, наберут одну фразу в поиске, результат — ноль, на этом и успокоятся, или сразу пойдут спрашивать, отвлекая от работы всех подряд.
              0

              Мне кажется, что это комплексная проблема. Не выстроен процесс документирования и обмена знаниями -> информация в доках неактуальна и/или не знаешь где смотреть -> все к этому привыкли -> теория разбитых окон — дока плохая, и улучшать ее все тяжелее и тяжелее -> уже не лезешь в доку, потому что ее считай что нет -> «проще спросить» -> выученная беспомощность, когда сам уже не можешь разобраться ни с чем новым и спрашиваешь у других вместо попыток разобраться/обращения к докам.

                0
                хорошо отлаженный процесс управления знаниями жизнь упрощает но от описанных проблем не спасает. Документирование процесс трудоемкий и пишут то что надо здесь и сейчас — просто ещё один способ коммуникаций
                  0
                  Странная какая-то задача у DevOps-а.
                  Если какой-то сервер не работает, то просто перегружается виртуалка на которой он не работает.
                  Если это не помогает, то проблема эскалируется на техподдержку облачного провайдера.
                  <:o)
                    0
                    Ладно, открою суровую правду. Спросить проще, чем подумать самому. Все. У вас может быть насколько угодно подробная и актуальная документация, но все равно будут люди которые спрашивают — им «некогда» читать «слишком длинные» тексты. Хотя на самом деле — просто лень и нежелание напрягать мозги.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое