[Bus Factor] Почему ваша незаменимость — это архитектурная уязвимость (SPOF), а не повод для гордости

Понедельник, 09:30. Вы открываете Slack, Telegram и Jira. Там уже горит. В личке пять непрочитанных: «Посмотри, тут прод упал», «Ты единственный знаешь, как работает этот костыль», «Без твоего аппрува не можем покатить релиз» . В этот момент в лимбической системе происходит мощный выброс дофамина. Включается режим Атланта. «Без меня тут всё рухнет. Я несущая стена этого карточного домика. Я избранный». Мысленно надевается плащ Супермена (поверх офисной рубашки или мятой футболки), расправляются плечи, берется ведро кофе и начинается операция «Спасение проекта». К вечеру ресурс батареи на нуле, глаз дергается, но есть глубокое удовлетворение. ЧСВ почесано, ценность для человечества доказана. Спойлер: Я сам жил в этом режиме несколько лет. И сейчас, глядя на логи, могу сказать честно. С точки зрения системной архитектуры это не героизм. Это классический паттерн SPOF (Single Point of Failure). Единая точка отказа. Инженер в такой позиции совсем не Супермен. Он тот самый старый сервер в углу, на который боятся дышать, потому что он держится на изоленте и честном слове. Сегодня поговорим о Bus Factor. Почему быть «священной коровой» проекта означает тупиковую ветвь эволюции для Сеньора. И как перестать быть инженером, которого боятся отправить в отпуск.

https://habr.com/ru/articles/996612/

#Bus_factor #карьера_в_it #управление_командой #архитектура #технический_долг #делегирование #knowledge_sharing #документация #отказоустойчивость #high_availability

Бас-фактор глазами водителя автобуса

В последнее время стало привычно ссылаться на бас-фактор , как на что-то, что обязательно похоронит ваш проект, если вы наймете хоть одного толкового специалиста. Бизнесу, якобы, нужны сплошь взаимозаменяемые винтики, с правильно вывернутым гетеродином лайф-ворк баланса, способные хорошо использовать данные свыше фреймворки и библиотеки. К сожалению, если у вас в команде нет звезд, вы никогда не сделаете звездный продукт. Магазин мягкой игрушки в Бирюлево, который будет вас худо-бедно кормить — запросто. А что-нибудь посерьезнее, поамбициознее и поприбыльнее — навряд ли. Потому что во всех серьёзных продуктах есть части, которые требуют оригинальных, пока необиблиотеченных, сложных решений. Я не говорю о бас-факторе (назовем его БФ первого рода, или БФ-1, в честь клея), который полностью спровоцирован дегенеративным дядькой, боящимся потерять работу, и оттого пишущем нечитаемый, только ему одному (им вдвоем с поллитрой) понятный, запутанный код. Если любой разработчик в команде не может, или не желает, объяснять свой код коллегам — его надо не просто выгнать, а повесить на позорном столбе перед воротам в ойти, чтобы всяк сюда входящий видел и знал, что бывает с такими вот саботажниками. К сожалению, такими нелицеприятными персонажами не исчерпываются все истоки возникновения бас-фактора. Основной, гораздо более частой, причиной — является то, что в команде есть только один человек, способный понять задачу корректно и воплотить ее в коде элегантно и безотказно . И что?

https://habr.com/ru/articles/971906/

#bus_factor #отказоустойчивость

«Один ушел — и все сломалось». Почему в ИТ-эксплуатации важно отслеживать Bus Factor и как это делаем мы

Привет всем! Меня зовут Гриша Капцов, я работаю в Отделе координации и поддержки продуктовых команд в МТС Web Services. В прошлом посте рассказывал , как мы с командой прокачали свой навык повелевания хаосом. А сегодня хочу обсудить ситуации, когда один «незаменимый» сотрудник становится угрозой. Представьте, что в вашей системе поднимается критический инцидент. Прод ложится, алерты строчат, клиенты негодуют. Вы открываете чат, а единственный человек, который знает, как это чинить, в отпуске. Или уволился. Или не выходит на связь. И что делать без него — вообще ноль идей. Ситуация может показаться гипотетической, но в сфере ИТ-эксплуатации это ежедневный риск, просто не всегда реализующийся. У вас может быть сильная команда и крутые инженеры, но при этом — один человек на зону знаний, отсутствие структурированной документации и полная слепота к ключевым уязвимостям. Предотвратить такие сценарии можно, если отслеживать «фактор автобуса», или Bus Factor — показатель зависимости проекта от отдельных членов команды. Ниже я расскажу, почему эта метрика особенно критична для эксплуатационных команд и как ее измеряем мы. Давайте назовем кейс «This is эксплуатация!».

https://habr.com/ru/companies/ru_mts/articles/955926/

#управление_продуктом #управление_проектами #управление_разработкой #управление_персоналом #itкомпании #управление_рисками #bus_factor #басфактор #басфактор

Снижаем bus-фактор: личный опыт, боли и решения

Представь, Бро. У тебя в команде есть один человек, который держит в голове все тонкости проекта. Архитектура - его. Сборки - его. Логика в бекенде, деплой, связи между модулями - тоже он. Всё работает идеально, пока он рядом. Но стоит ему уйти в отпуск, заболеть или, как говорится, попасть под автобус - и всё, команда в ауте, сроки летят, клиенты в шоке. Это и есть тот самый bus-фактор. В этой статье разберём, почему это не круто, как он возникает, почему так распространён, и главное - как его снизить. Поделюсь личными кейсами, проверенными практиками и нетривиальными приёмами, которые реально работают. Без воды, честно и с примерами из боевого менеджмента.

https://habr.com/ru/articles/910102/

#busфактор #bus_factor #делегирование #управление_командой #project_management #project_manager #agile #scrum #onetoone

Нужна ли документация на проекте?

Вопрос о необходимости документации при разработке вызывает много споров. В динамичном мире IT, где изменения стремительны, я часто слышал холиварные обсуждения: а так ли необходима документация? Кто-то считает, что программный код сам по себе уже исчерпывающая документация. В моей прошлой статье было несколько комментариев с утверждениями, что документацию вести необязательно, достаточно кодовой базы и условного OpenAPI. В прошлой статье я рассказывал, как работал в проектах без документации. В этот раз под катом опишу аргументы в пользу ведения документации и поддержания её в актуальном состоянии.

https://habr.com/ru/companies/alfa/articles/858942/

#документация #аналитика #управление_проектами #bus_factor #спецификация_на_разработку #сайзинг #описание_проекта #минимизация_рисков

[Перевод] Проверяем фактор автобуса для опенсорсных проектов

Из Википедии : фактор автобуса (англ. bus factor, либо truck factor) проекта — это мера сосредоточения информации среди отдельных членов проекта; фактор показывает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками. Мотивация Во всех компаниях, где я работал (в строительстве и разработке ПО), в тот или иной момент времени возникал вопрос «фактора автобуса» в управлении разработкой проектов. Инженеру-строителю вычислить его было крайне сложно, потому что наша отчётная документация была сильно распределена между сотрудниками и существовал дефицит документации. Единственный раз, когда это стало очевидно, случился после увольнения одного из сотрудников — спустя полгода возник срочный запрос RFI (запрос информации) по чьему-то пакету расчётов (хотя официальный пакет должен быть подписан инженером-проектировщиком, а не инженером, непосредственно отвечающим за расчёты). После таких инцидентов нам обещали улучшить документацию, но это неизбежно отходило на второй план, когда все участники группы переходили на новые проекты даже без итогового совещания. Я был свидетелем того, как в долговременных проектах инженерный состав менялся на 100%, поэтому это ужасный антипаттерн. В разработке ПО можно провести множество параллелей, но по природе нашей работы поставка выпущенного кода — это единственный способ измерения фактора автобуса. По крайней мере, именно её изучали многие исследователи, в том числе и в научной статье , имеющей большое количество цитирований (156, согласно Google Scholar!) с момента её публикации в 2016 году ( препринт выпустили в 2015 году). Ша отправил мне статью, а после того, как мы обнаружили её исходные данные и исходный код , это стало идеальным проектом на выходные, который бы позволил, как минимум, получить представление об интересных метриках open source.

https://habr.com/ru/articles/858374/

#фактор_автобуса #bus_factor #мейнтейнеры