Комментарии 8
Чтобы выяснить, что именно делал Игнатий для того, чтобы процедура отрабатывала корректно и на слайде отображались актуальные данные, потребовалось 4 человеко-часов работы двух других аналитиков.
Всего 4? Игнатий был образцом документирования и сохранения информации о своей работе!
Автор, по-моему, Вы не понимаете значение слова "disclaimer".
Крик души вижу я в этом материале. Поддержу, причём со стороны эксплуатации. Ибо решение проблем пользователей (админов прикладного сервиса в админке) по алгоритму:
выяснить белые
IP-адреса сервиса;уточнить, что слушает эти адреса - железо, и какое - F5, cisco, etc; ПО - nginx, IPVS, etc;
если ПО - глянуть в логи, что там, ИНОГДА помогает локализовать проблему;
выяснить, на какие хосты проваливаются запросы с фронта;
изучить логи ПО, на которое проваливается фронт;
если проблема дальше - идти дальше; И так - пока не будет найден проблемный узел (узлы/ПО).
вообще не впечатляет.
Мониторинг - работает. Все сервисы на читающие запросы отвечают 200, проблемы возникают при редактировании/создании материалов и заливке больших мультимедиа-файлов. Или при выдаче видео-контента, там свои тараканы были в те времена.
В эскплуатации отсутствие документации - это вообще штатная ситуация. :(
По существу же.
Необходимы правила/стандарты/шаблоны ведения документации. Чтобы документация воспринималась именно документацией, а не сборником сочинений на свободную тему.
А дело не в документации, отсутствии желания её писать или читать, и даже не в мнимой "ценности пока это знаешь только ты". Для того, чтобы это победить, нужен простой советский...
Умение декомпозировать в голове задачи. Для того, чтобы описать последовательность шагов Игната, нужно не раз в неделю с горящей пятой точкой что-то там хардкодить, а сесть и подумать, почему вообще что-то надо хардкодить. Разложить процесс на этапы, немношк напрячься - и вот с одной стороны в голове сформировался алгоритм, как это работает, с другой - как это должно работать. И тогда записать не сложно, в этом нет никакой проблемы. Это одна сторона проблемы.
Другая сторона - при реализации приложения / отчета была допущена ошибка. Во время декомпозиции не подумали, что что-то надо написать, кроме своего имени в Jira при списании человекочасов. Не подумал исполнитель, не подумал заказчик, как итог - вот такая вот ситуация. И дело не в том, что у кого-то KPI не было - не было понимания, что эту работу надо сделать в принципе.
Иными словами, с аналитическим и структурным мышлением порой сложно у специалистов. В статье описаны шаги, как починить сломанное, а вот как предотвратить поломку - это гайды из другой области. К сожалению. Мне бы хотелось, чтобы подобные проблемы решались просто чек-листом, но без понимания причинно-следственной связи это будет работа из-под палки
Вообще, по поводу документации, мозги встают на место на 5-7 год работы в любой компании с ОПО и численностью более 1k.
Благодарю. Это важно!
Без документации проект живёт до первого отпуска разработчика. Потом начинаются гадания по коду и поиски того самого скрипта, который "все помнят, но никто не видел"
Документация как навык выживания