понедельник, 10 декабря 2012 г.

Самоорганизующиеся высоконадежные организации (revised edition)

Тут недавно cartmendum вспомнил одну замечательную статью: "The Self-Designing High-Reliability Organization: Aircraft Carrier Flight Operations at Sea"

Статья рассказывает про авианосцы, как пример большой организации, занятой сложной технической работой, факапы в которой крайне нежелательны. Собственно американский авианосец приводится как пример организации, которая очень хорошо справляется с тем, чтобы факапов было как можно меньше.

Можно долго спорить с тем, что ближе к разработке ПО этот наш авианосец или производство машин в недрах toyota. На мой взгляд и то и то достаточно далеко, но не в этом суть. Суть в том, что и там и там есть проблемы, которые в разработке и сопровождении ПО встречаются регулярно. А есть проблемы, которые нашему менеджменту только в страшном сне снятся. И при этом и там и там с ними справляются несколько лучше, чем в разработке ПО. Так что вместо того, чтобы примерять к IT авианосец просто выделю несколько ключевых, на мой взгляд, моментов, которые авторы статьи упоминают как средства сокращения факапов на авианосце:

  • Тесные взаимозависимости между различными групами
  • Тесная взаимная координация и обмен информацией, как результат частично дублирующихся знаний
  • Высокая операционная избыточность - много разных людей наблюдают за одними и теми же событиями и обмениваются наблюдаемой информацией
  • Широкое толкование того, кто принадлежит к команде
  • Сокомандники включаются в коммуникационные цепочки, а не исключаются из них
  • Регулярная работа над ошибками
  • Высокий уровень понимания текущей ситуации - поддерживается постоянное понимание того, что сейчас происходит и какова вероятность тех или иных факапов
  • Высокий уровень навыков межличностного общения
  • Хранение детальных данных о прошлых факапах, которые внимательно пересматриваются с целью обучения
  • Командная цепочка изменяется для того, чтобы отвечать текущей ситуации - высокая организационная гибкость
  • Сообщения о просчетах и ошибках вознаграждаются, а не наказываются
Посмотрите на этот список. Посмотрите на организацию, в которой вы работаете. И крепко задумайтесь.

В agile даже просматриваются какие-то зачатки этого списка (кроссфункциональность, стендапы, доски...). Увы только зачатки. Увы зачастую идолизируются артефакты и полностью забывается главная цель, которой, в данном случае, является снижение факапов на производстве.

9 комментариев:

  1. слово "избыточный" я мог бы подставить почти в каждую характеристику. То есть секрет не-факапов в огромном объеме выделенных на эти задачи ресурсов - в виде количества и качества людей, многократно перекрывающих одну и туже задачу.

    ОтветитьУдалить
    Ответы
    1. У меня это слово только в три пункта подставляется нормально.

      Ну и все же избыточность сама по себе недостаточна для сокращения факапов. "Зенит" и наш государственный аппарат тому отличны примеры (есть более серьезные примеры). К тому же в случае людей есть много но. Избыточность людей в одной точке не должна приводить к:
      - Снижению/повышению рабочей нагрузки
      - Усложнению коммуникаций, иерархии и устройства рабочих ячеек

      Плюс в ряде случаев большое количество людей на задаче приводит к тому, что situation awareness совсем исчезает. А избыточность людей на руководящих должностях как правило приводит к потере оранизационной гибкости.

      Итого: избыточность это простой способ сократить факапы, но она подходит не для всех задач и сама по себе недостаточна, т.к. все еще требует ряда дополнительных условий (иначе рискуем получить неработающую бюрократию).

      Удалить
    2. Вот на зенит батоны крошить не надо!

      Удалить
    3. Терминологически всё же не "избыточность", а "многократное резервирование" по всем аспектам. Но это в лучшем случае начинается в момент, когда всё переходит из девелопмента в продакшн. А думать об этом правильнее с самого начала, на этапе проектирования, иначе всё это резервирование и саморегуляция будет чужеродны по отношению к объекту.
      Что, впрочем, необязательно плохо: на прошлом кодефесте рассказывали - "нам нет смысла разбираться, почему упал один из нодов - мы его немедленно убиваем и поднимаем свежий клон". =Время жизни пехотинца в бою= - в чистом виде.

      Что у нас на эту тему говорят руководства по эксплуатации всяких потенциально опасных объектов - энергетика, химзаводы, ядерные станции? А сколько "девяток" аптайма должен обеспечить грамотно построенный облачный сервис? Какое время восстановления?

      Удалить
    4. В моем случае после ухода в продакшен опять идет разработка, а потом опять продакшен и так до бесконечности. После первого выхода в продакшен я уже не вижу смысла серьезно разделять эксплуатацию и разработку. Оно друг с другом очень плотно связано.

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

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

      Еси говорить про облачные сервисы, то там как SLA напишите так и будет. А дальше торги с клиентом. Если говорить про тех, кто интернетами деньги зарабатывает напрямую, то для того же ебея две девятки после запятой это примерно 8 миллионов долларов из кармана прямых потерь.

      Удалить
    5. Про избыточность в пунктах -

      Тесные взаимозависимости между различными групами
      >> это дополнительные коммуникации

      Тесная взаимная координация и обмен информацией, как результат частично дублирующихся знаний
      >> это дополнительный ресурс на передачу и мониторинг информации

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

      Широкое толкование того, кто принадлежит к команде
      >> это дополнительные люди в системе (больше минимума)

      Сокомандники включаются в коммуникационные цепочки, а не исключаются из них
      >> это дополнительный ресурс на мониторинг информации

      Регулярная работа над ошибками
      >> это дополнительный ресурс на анализ и сбор

      Высокий уровень понимания текущей ситуации - поддерживается постоянное понимание того, что сейчас происходит и какова вероятность тех или иных факапов
      >> это дополнительный ресурс на мониторинг + сверх-компетентность

      Высокий уровень навыков межличностного общения
      >> это сверх-компентность

      Хранение детальных данных о прошлых факапах, которые внимательно пересматриваются с целью обучения
      >> это дополнительный ресурс на сбор, упорядочивание и анализ

      Командная цепочка изменяется для того, чтобы отвечать текущей ситуации - высокая организационная гибкость
      >> это дополнительные люди в системе + сверх-компетентность

      Сообщения о просчетах и ошибках вознаграждаются, а не наказываются
      >> это единственная не дополнительно- и не сверх- характеристика

      Авторы сами прямо говорят, что секрет в redundancy. Это безусловно не является чем-то плохим, но это привилегия "богатых" проектов.

      Удалить
    6. Тут есть пара ньюансов:
      1. Оперировать на минимальных ресурсах это самоубийство. Особенно если речь идет о боевой эксплуатации онлайн-сервисов.
      2. Часть вещей делается практически бесплатно, нужно просто создать условия для правильных коммуникаций и поработать над культурой в компании. Никаких ресурсов на мониторинг, сбор, упорядочивание и т.п. тратить не придется. Это как корпоративная вики - если все сделать правильно, то очень крутой внутренний ресурс, но у некоторых все равно свалка получается.

      Т.е. если мы отметаем "самоубийц-нищебродов" как тупиковую ветвь эволюции, то избыточность все равно будет. Дальше вопрос в том как ей распорядиться и насколько большой этот запас.

      Удалить
  2. А как на твой взгляд на практике можно было бы реализовать следующее:

    "Тесная взаимная координация и обмен информацией, как результат частично дублирующихся знаний", особенно интересно дублирующиеся знания. Типа админов учим немного кодить, разрабов админить, и всех подряд немного приучаем пользоваться тестовой средой. Так?

    А "Широкое толкование того, кто принадлежит к команде"? Это как?

    Все остальное худо-бедно понятно. Как к этому прийти не понято, но на что оно похоже, когда к этому придешь, в общих чертах просматривается.

    ОтветитьУдалить
    Ответы
    1. > Типа админов учим немного кодить, разрабов админить, и всех подряд немного приучаем пользоваться тестовой средой. Так?

      Да. Шарим контроль версий на админов, тестеров и разрабов. Шарим мониторинг на всех. Шарим тестовую инфраструктуру на всех. Все могут худо-бедно работать везде (с небольшими оговорками и правилами, чтобы бардак не создавать). Это, кстати, понимание текущей ситуации улучшает и, если что, все знают куда смотреть.

      > А "Широкое толкование того, кто принадлежит к команде"?

      Это когда тестировщик иногда фиксит баги, разработчик разруливает факапы на бою, а админ пишет тесты. И отправка, скажем, разработчика на пару недель поработать в саппорте это не наказание, а нормальный обмен невербализируемым опытом между отделами.


      Примечательно, что в маленьких конторах такое обычно и так есть (ввиду отсутствия полноценной возможности разделения труда), а в больших зачастую нет (разделение труда несколько больше чем нужно).

      Удалить