Статья рассказывает про авианосцы, как пример большой организации, занятой сложной технической работой, факапы в которой крайне нежелательны. Собственно американский авианосец приводится как пример организации, которая очень хорошо справляется с тем, чтобы факапов было как можно меньше.
Можно долго спорить с тем, что ближе к разработке ПО этот наш авианосец или производство машин в недрах toyota. На мой взгляд и то и то достаточно далеко, но не в этом суть. Суть в том, что и там и там есть проблемы, которые в разработке и сопровождении ПО встречаются регулярно. А есть проблемы, которые нашему менеджменту только в страшном сне снятся. И при этом и там и там с ними справляются несколько лучше, чем в разработке ПО. Так что вместо того, чтобы примерять к IT авианосец просто выделю несколько ключевых, на мой взгляд, моментов, которые авторы статьи упоминают как средства сокращения факапов на авианосце:
- Тесные взаимозависимости между различными групами
- Тесная взаимная координация и обмен информацией, как результат частично дублирующихся знаний
- Высокая операционная избыточность - много разных людей наблюдают за одними и теми же событиями и обмениваются наблюдаемой информацией
- Широкое толкование того, кто принадлежит к команде
- Сокомандники включаются в коммуникационные цепочки, а не исключаются из них
- Регулярная работа над ошибками
- Высокий уровень понимания текущей ситуации - поддерживается постоянное понимание того, что сейчас происходит и какова вероятность тех или иных факапов
- Высокий уровень навыков межличностного общения
- Хранение детальных данных о прошлых факапах, которые внимательно пересматриваются с целью обучения
- Командная цепочка изменяется для того, чтобы отвечать текущей ситуации - высокая организационная гибкость
- Сообщения о просчетах и ошибках вознаграждаются, а не наказываются
Посмотрите на этот список. Посмотрите на организацию, в которой вы работаете. И крепко задумайтесь.
В agile даже просматриваются какие-то зачатки этого списка (кроссфункциональность, стендапы, доски...). Увы только зачатки. Увы зачастую идолизируются артефакты и полностью забывается главная цель, которой, в данном случае, является снижение факапов на производстве.
слово "избыточный" я мог бы подставить почти в каждую характеристику. То есть секрет не-факапов в огромном объеме выделенных на эти задачи ресурсов - в виде количества и качества людей, многократно перекрывающих одну и туже задачу.
ОтветитьУдалитьУ меня это слово только в три пункта подставляется нормально.
УдалитьНу и все же избыточность сама по себе недостаточна для сокращения факапов. "Зенит" и наш государственный аппарат тому отличны примеры (есть более серьезные примеры). К тому же в случае людей есть много но. Избыточность людей в одной точке не должна приводить к:
- Снижению/повышению рабочей нагрузки
- Усложнению коммуникаций, иерархии и устройства рабочих ячеек
Плюс в ряде случаев большое количество людей на задаче приводит к тому, что situation awareness совсем исчезает. А избыточность людей на руководящих должностях как правило приводит к потере оранизационной гибкости.
Итого: избыточность это простой способ сократить факапы, но она подходит не для всех задач и сама по себе недостаточна, т.к. все еще требует ряда дополнительных условий (иначе рискуем получить неработающую бюрократию).
Вот на зенит батоны крошить не надо!
УдалитьТерминологически всё же не "избыточность", а "многократное резервирование" по всем аспектам. Но это в лучшем случае начинается в момент, когда всё переходит из девелопмента в продакшн. А думать об этом правильнее с самого начала, на этапе проектирования, иначе всё это резервирование и саморегуляция будет чужеродны по отношению к объекту.
УдалитьЧто, впрочем, необязательно плохо: на прошлом кодефесте рассказывали - "нам нет смысла разбираться, почему упал один из нодов - мы его немедленно убиваем и поднимаем свежий клон". =Время жизни пехотинца в бою= - в чистом виде.
Что у нас на эту тему говорят руководства по эксплуатации всяких потенциально опасных объектов - энергетика, химзаводы, ядерные станции? А сколько "девяток" аптайма должен обеспечить грамотно построенный облачный сервис? Какое время восстановления?
В моем случае после ухода в продакшен опять идет разработка, а потом опять продакшен и так до бесконечности. После первого выхода в продакшен я уже не вижу смысла серьезно разделять эксплуатацию и разработку. Оно друг с другом очень плотно связано.
УдалитьПро падение ноды был тут в сентябре показательный случай - у гитхаба начали падать ноды базы данных, а через сутки корневая нода самоубилась. С проблемами надо разбираться, а то они накапливаются и вся ваша классная система летит к чертям как карточный домик. А свежий клон это просто заглушка. Поддержание аптайма, пока на заднем фоне тушат пожар. Очень плохо, когда пехотинцы начинают дохнуть как мухи и не прекращают делать этого.
На энергетике, химзаводах и ядерных станциях бывают операционные сбои. И там очень хорошо понимают, что с их причинами надо разбираться сразу, а то потом плохо будет. Ну или не разбираться, если вам выгоднее пару раз в год на приличные деньги отправлять пару калек. Капитализм в этих областях довольно чудовищный, в том числе в том городе, где я живу.
Еси говорить про облачные сервисы, то там как SLA напишите так и будет. А дальше торги с клиентом. Если говорить про тех, кто интернетами деньги зарабатывает напрямую, то для того же ебея две девятки после запятой это примерно 8 миллионов долларов из кармана прямых потерь.
Про избыточность в пунктах -
УдалитьТесные взаимозависимости между различными групами
>> это дополнительные коммуникации
Тесная взаимная координация и обмен информацией, как результат частично дублирующихся знаний
>> это дополнительный ресурс на передачу и мониторинг информации
Высокая операционная избыточность - много разных людей наблюдают за одними и теми же событиями и обмениваются наблюдаемой информацией
>> это дополнительный ресурс на мониторинг
Широкое толкование того, кто принадлежит к команде
>> это дополнительные люди в системе (больше минимума)
Сокомандники включаются в коммуникационные цепочки, а не исключаются из них
>> это дополнительный ресурс на мониторинг информации
Регулярная работа над ошибками
>> это дополнительный ресурс на анализ и сбор
Высокий уровень понимания текущей ситуации - поддерживается постоянное понимание того, что сейчас происходит и какова вероятность тех или иных факапов
>> это дополнительный ресурс на мониторинг + сверх-компетентность
Высокий уровень навыков межличностного общения
>> это сверх-компентность
Хранение детальных данных о прошлых факапах, которые внимательно пересматриваются с целью обучения
>> это дополнительный ресурс на сбор, упорядочивание и анализ
Командная цепочка изменяется для того, чтобы отвечать текущей ситуации - высокая организационная гибкость
>> это дополнительные люди в системе + сверх-компетентность
Сообщения о просчетах и ошибках вознаграждаются, а не наказываются
>> это единственная не дополнительно- и не сверх- характеристика
Авторы сами прямо говорят, что секрет в redundancy. Это безусловно не является чем-то плохим, но это привилегия "богатых" проектов.
Тут есть пара ньюансов:
Удалить1. Оперировать на минимальных ресурсах это самоубийство. Особенно если речь идет о боевой эксплуатации онлайн-сервисов.
2. Часть вещей делается практически бесплатно, нужно просто создать условия для правильных коммуникаций и поработать над культурой в компании. Никаких ресурсов на мониторинг, сбор, упорядочивание и т.п. тратить не придется. Это как корпоративная вики - если все сделать правильно, то очень крутой внутренний ресурс, но у некоторых все равно свалка получается.
Т.е. если мы отметаем "самоубийц-нищебродов" как тупиковую ветвь эволюции, то избыточность все равно будет. Дальше вопрос в том как ей распорядиться и насколько большой этот запас.
А как на твой взгляд на практике можно было бы реализовать следующее:
ОтветитьУдалить"Тесная взаимная координация и обмен информацией, как результат частично дублирующихся знаний", особенно интересно дублирующиеся знания. Типа админов учим немного кодить, разрабов админить, и всех подряд немного приучаем пользоваться тестовой средой. Так?
А "Широкое толкование того, кто принадлежит к команде"? Это как?
Все остальное худо-бедно понятно. Как к этому прийти не понято, но на что оно похоже, когда к этому придешь, в общих чертах просматривается.
> Типа админов учим немного кодить, разрабов админить, и всех подряд немного приучаем пользоваться тестовой средой. Так?
УдалитьДа. Шарим контроль версий на админов, тестеров и разрабов. Шарим мониторинг на всех. Шарим тестовую инфраструктуру на всех. Все могут худо-бедно работать везде (с небольшими оговорками и правилами, чтобы бардак не создавать). Это, кстати, понимание текущей ситуации улучшает и, если что, все знают куда смотреть.
> А "Широкое толкование того, кто принадлежит к команде"?
Это когда тестировщик иногда фиксит баги, разработчик разруливает факапы на бою, а админ пишет тесты. И отправка, скажем, разработчика на пару недель поработать в саппорте это не наказание, а нормальный обмен невербализируемым опытом между отделами.
Примечательно, что в маленьких конторах такое обычно и так есть (ввиду отсутствия полноценной возможности разделения труда), а в больших зачастую нет (разделение труда несколько больше чем нужно).