Понятие HumanOps родилось в Server Density в результате накопления значительного опыта работы по мониторингу компьютерных систем и, соответственно, пребывания команды в состоянии постоянной готовности. В первые годы существования компании я долгое время был на связи в режиме 24/7. Однако по мере роста команды мы внедряли процессы и политики, целью которых было распределение нагрузки и снижение негативного влияния случаев, когда сотрудников отрывают от текущей работы или звонят во внеурочное время, в том числе и ночью.
В процессе создания и распространения продукта, предназначенного для того, чтобы будить людей, мы обратили внимание, что наши клиенты испытывают схожие с нашими проблемы, связанные с пребыванием в состоянии постоянной готовности. Общение с клиентами убедило нас, что такие проблемы характерны для индустрии, и поэтому мы решили критически взглянуть на применяемые подходы, а также изучить лучшие практики, используемые другими участниками рынка. В итоге это привело к созданию сообщества по выработке и обсуждению ряда принципов, которые получили название HumanOps.
Мы надеемся, что аналогично практикам DevOps, ускоряющим развертывание, приносящим новые инструменты, а также объединяющим команды разработки и эксплуатации, HumanOps поможет организациям в освоении более «человечного» подхода к построению систем и работе с ними.
Под катом вы найдете 12 принципов HumanOps и описание их работы на примере Server Density.
1. Люди создают системы и решают возникшие с ними проблемы
В центре внимания HumanOps находятся люди, которые создают, используют и поддерживают системы. Для кого-то это может показаться очевидным, но все же крайне важно сформулировать эту идею в качестве первого принципа, поскольку без признания того, что работа систем невозможна без участия людей, слишком легко начать думать только о серверах, сервисах и API.
На практике это означает, что при проектировании систем вы с самого начала учитываете людей, которые будут так или иначе с ними взаимодействовать.
Что нужно принимать во внимание:
- Какие части системы могут быть автоматизированы? Необходимо стараться избегать участия людей в ежедневных рутинных операциях, прибегая к силе человеческого интеллекта только в тех случаях, когда система не может исправить проблему сама.
- Какие сигналы тревоги для оповещения людей необходимо настроить? В какой момент потребуется вмешательство человека? Критично ли это? Можно ли отложить решение проблемы на стандартные рабочие часы?
- После того как вмешательство человека произошло, каким образом об этом становится известно команде и руководству? Вы ведете журнал поступивших во внеурочное время оповещений, анализируете тенденции?
2. Люди устают и испытывают стресс, они бывают счастливы и несчастны
С этого надо начинать проработку улучшения процессов. Используя компьютеры, мы небезосновательно ожидаем, что они будут работать одинаково независимо от времени суток. Это, безусловно, одно из ключевых преимуществ компьютерных систем — они могут, не уставая, надежно выполнять поставленные задачи.
Однако многие ошибочно пытаются применять такую же логику по отношению к людям. Важно учитывать, что люди в разных ситуациях действуют по-разному. Эмоции, стресс и усталость снижают предсказуемость поведения системы, поэтому эти факторы необходимо принимать во внимание при проектировании.
В качестве примера рассмотрим человеческий фактор. Компьютеры не совершают ошибок. Они не нажимают на не ту кнопку по причине усталости. Люди на такое способны, и даже, скорее всего, где-то ошибутся, если не была проведена должная подготовка, а в систему не встроена соответствующая защита. Человеческий фактор — это неотъемлемая часть системы, которую надо очень хорошо понимать. Этот феномен необходимо рассматривать скорее как симптом, нежели как проблему саму по себе, а его проявления должны побуждать к более внимательному изучению ситуации, в которой человек принял неправильное решение.
Один из путей улучшения ситуации — это обучение. Обучение должно быть максимально приближено к реальности, чтобы в тот момент, когда проблема произошла в действительности, она воспринималась бы так же, как и при обучении. Таким образом снижается стресс, поскольку сотрудники знают, что нужно делать. Стресс возникает из-за неуверенности вкупе с осознанием того, что система не работает, поэтому нужно всячески стараться смягчать подобное влияние нештатных ситуаций на психику. Для моделирования различных сценариев сбоев мы проводим военные игры. Таким образом, все сотрудники в любой из отработанных ситуаций знают, что нужно делать.
3. У систем пока нет чувств, но есть SLA
Соглашение об уровне предоставления услуги (SLA) — это отработанный метод определения того, что вы можете ожидать от определенного сервиса или API. У вас должна быть возможность легко определить, соответствует ли сервис SLA, а также что делать, если не соответствует.
4. Людям нужно иногда отключаться
Аналогично принципу № 2, в отличие от компьютеров, которые могут безостановочно работать месяцами и годами, людям требуется отдых. Реагируя на нештатные ситуации и имея дело со сложными системами, люди быстро устают, поэтому время на отдых и восстановление должно быть неотъемлемой частью процессов. Человек может сохранять концентрацию лишь в течение 1,5–2 часов, после этого ему потребуется перерыв. В противном случае работоспособность начинает снижаться.
В Server Density мы решаем эту проблему с помощью ротации дежурств. Первичная и вторичная (primary/secondary) роли по очереди переходят членам команды, и у нас есть документы, определяющие время реакции в зависимости от роли. Это позволяет уменьшить ощущение невозможности отойти от своего компьютера. Например, специалист на подстраховке (secondary) не обязан реагировать мгновенно, поэтому ему не нужно постоянно быть рядом с компьютером.
Более того, время на отдых после работы во внеурочные часы у нас выделяется автоматически. Сотрудник по желанию может отказаться от него, но компания никогда не просит это сделать. Таким образом, мы уверены, что у сотрудников есть достаточно времени на восстановление и на них никто не давит с целью вынудить отказаться от него. Например, это достигается за счет именно автоматического предоставления отдыха — сотруднику не надо ничего делать, чтобы его получить.
5. Благополучие людей-операторов влияет на надежность систем
Может показаться, что мы даем нашим сотрудникам отдохнуть после реагирования на инциденты во внеурочное время только лишь из хорошего человеческого к ним отношения. Однако здесь есть и бизнес-логика: переутомленные люди делают ошибки, и мы знаем много примеров крупных аварий, которые были усугублены или спровоцированы усталостью операторов.
Как и со страховкой, которой вы надеетесь никогда не воспользоваться, бывает тяжело рассчитать прямую выгоду такого подхода. Смысл снижения вероятности совершения человеческой ошибки в том, чтобы избежать чего-то плохого. Это сложно измерить, но, без сомнения, есть железная логика в том, чтобы стремиться к хорошему самочувствию операторов, поскольку в этом случае они будут принимать более качественные решения.
6. Тревожная усталость == человеческая усталость
Тревожная усталость (alert fatigue) возникает от получения слишком большого количества сигналов тревоги. Этих сигналов так много, что оператор начинает их игнорировать, рискуя пропустить что-то важное. Это явление значительно снижает эффективность системы оповещения, которая должна срабатывать в редких случаях, ставя людей в известность о том, что произошло что-то действительно серьезное.
Для решения этой проблемы необходимо проводить аудит системы мониторинга, проверяя, требуют ли генерируемые сигналы тревоги совершения каких-либо действий, а также что эти действия на самом деле совершаются.
7. Автоматизируйте что только возможно, привлекайте людей лишь в крайнем случае
Этот принцип связан с предыдущим, поскольку сигналы тревоги должны передаваться людям только в тех случаях, когда система не может починить себя сама. Не нужно будить человека, чтобы перезагрузить сервер или выполнить другое простое действие. Если что-то может быть автоматизировано, то лучше так и поступить. Люди должны привлекаться лишь для оценки сложных ситуаций и выполнения нестандартных действий.
К сожалению, после сдачи системы в промышленную эксплуатацию дальше что-то автоматизировать достаточно проблематично. Это происходит по той причине, что, используя такие современные технологии, как Kubernetes и облачные API, можно настроить автоматическое восстановление после практически любого сбоя, но при этом требуется очень много усилий для адаптации новых технологий к старым системам. Безусловно, и использование избыточности, и внедрение чего-то нового стоят денег, но эти затраты окупаются за счет экономии времени работы человека и увеличения общей надежности систем.
Правильный подход к построению инфраструктуры заключается в том, что ничего в условиях промышленной эксплуатации не должно делаться вручную. Все должно быть шаблонизировано, оформлено в виде сценариев и выполняться автоматически.
При модернизации старой инфраструктуры необходимо соблюдать баланс, поскольку, например, контейнеризация основных компонентов сис��емы может оказаться нецелесообразной. Однако есть пути по достижению схожих целей, например, перенос размещенной на собственном оборудовании базы данных в управляемый сервис типа AWS RDS.
8. Документируйте все, учите всех
В реальной жизни никто не любит писать документацию, но по мере роста команды и усложнения системы это быстро становится необходимостью. Вам нужно достаточное количество документации, которую сможет использовать человек с ограниченным пониманием внутренних механизмов системы. Для решения проблем с помощью документации могут применяться контрольные списки (checklists) и плейбуки.
Обучение не менее важно. Оно в числе прочего помогает выявить недостатки документации. Также жизненно необходимо проводить реалистичные симуляции с участием сотрудников, отвечающих на инциденты, и объяснять им как работает система.
Чтобы сделать документацию удобной для поиска и легкодоступной для всех сотрудников компании, мы в Server Density используем Google Drive. Однако существует еще немало других вариантов по ее размещению.
9. Не надо никого стыдить и обвинять
При поиске причины возникновения проблемы практически всегда будет найден сотрудник, который совершил ошибку, не запланировал все возможные сценарии, сделал неверное предположение или написал плохой код. Это нормально, и людей не нужно за это стыдить, поскольку в следующий раз они вряд ли захотят помогать в расследовании инцидента.
Идеальных людей нет. Каждый из нас хоть раз ломал что-то в production. Здесь важно не обвинять конкретного человека, а суметь сделать систему лучше и устойчивее к подобного рода проблемам. Такого практически никогда не бывает, чтобы система была сломана сознательно, поэтому люди не должны испытывать проблем в признании своих ошибок сразу же после осознания содеянного. Это важно для быстрой ликвидации последствий. Неудачи должны рассматриваться как возможность научиться и сделать команду лучше.
Этого можно добиться с помощью никого не обвиняющего анализа причин сбоя, в процессе которого выясняются детали и основная причина произошедшего, но люди, совершившие ошибку, не называются.
10. Проблемы людей — это проблемы системы
Существует тенденция рассматривать проблемы людей и проблемы систем по отдельности. Гораздо проще обосновать дополнительные затраты на увеличение производительности серверов и отказоустойчивость, нежели на вопросы, связанные с персоналом. Все вышеперечисленные принципы призваны подчеркнуть, что вопросы, связанные с людьми, не менее важны и им нужно уделять соответствующее время на рассмотрение и бюджет.
В Server Density при планировании циклов разработки мы часто приоритезируем задачи на основе их потенциала по уменьшению количества нештатных ситуаций, требующих участия людей во внеурочное время. Реализация исправлений проблем, выявленных в ходе анализа причин сбоя, получает более высокий приоритет, если в процессе реагирования на ситуацию пришлось поднимать с постели людей или у проблемы, по крайней мере, есть такой потенциал.
11. Здоровье людей влияет на здоровье бизнеса
Поскольку здоровье и благополучие людей влияет на их работу, в том числе на способность вносить вклад в общее дело по решению возникающих проблем, а проблемы системы приводят к уменьшению прибыли и порче репутации, здоровье людей имеет прямое влияние на здоровье бизнеса. Процесс поиска новых сотрудников отнимает много времени и сил, поэтому забота о людях выгодна для бизнеса.
12. Люди важнее систем
Несмотря на то что, несомненно, важно рассматривать людей и системы находящимися на одном уровне по степени влияния друг на друга и бизнес в целом, по большому счету люди все же важнее. Ведь для чего существует бизнес? Чтобы продавать товары и услуги другим людям! И зачем люди делают определенную работу, как не для получения средств к существованию?
Улучшение условий работы вашей команды достаточно легко обосновать. Чтобы иметь возможность нанимать и удерживать лучших специалистов, ваши рабочие процессы должны быть хорошо отлажены. Когда людей постоянно поднимают с постели, стыдят за ошибки и не исправляют проблемы, это негативно сказывается на их состоянии. Стресс, испытываемый на протяжении продолжительных периодов времени, может вызвать повышенное кровяное давление, заболевания сердца, ожирение и диабет. Таким образом, многие организации, не уделяя достаточного внимания вопросам благополучия персонала, могут непреднамеренно подрывать здоровье своих сотрудников, причем иногда очень серьезно.
Мы в Server Density считаем, что это недопустимая цена успешности бизнеса.
Ссылки:
- Оригинал: How we do HumanOps at Server Density.