Чьи-то принципы становятся чьими-то инструкциями. К примеру, использование HTTP/REST можно назвать принципом, а не инструкцией, и в этом не будет ничего плохого. Дело в том, что ценность представляет наличие всеобъемлющих идей, дающих представление о ходе развития системы, и наличие достаточной детализации, позволяющей описать способы осуществления этих идей. Возможно, в объединении принципов и инструкций не будет ничего плохого, если речь идет о небольшой группе команд или даже об одной команде. Но для более крупных организаций, в которых могут применяться различные технологии и рабочие инструкции, для разных мест могут понадобиться разные инструкции, и при этом все они будут соответствовать общему набору принципов. Например, у. NET-команды может быть один набор инструкций, а у Java-команды — другой наряду с наличием набора инструкций, общего для обеих команд. А вот принципы у них должны быть общими.
В ходе работы с одним из наших клиентов мой коллега, Эван Ботчер (Evan Bottcher), разработал схему, показанную на рис. 2.1. На рисунке продемонстрирована взаимосвязь целей, принципов и инструкций в очень ясной форме. В течение нескольких лет инструкции будут меняться, в то время как принципы останутся прежними. Такую схему можно распечатать на большом листе бумаги и повесить на видном месте.
Неплохо бы иметь документацию, разъясняющую некоторые из этих пунктов. Но все же мне больше нравится идея иметь в развитие этих замыслов примеры кода, которые можно было бы рассмотреть, изучить и запустить. Еще лучше создать инструментальные средства, допускающие только правильные действия. Все это скоро будет рассмотрено более подробно.
При проработке инструкций и размышлении насчет компромиссов, на которые необходимо пойти, нужно определить и такой очень важный момент, как допустимая степень изменчивости вашей системы. Одним из основных способов определения неизменных качеств для всех сервисов является установка критериев отбора тех из них, поведение и качество которых не выходят за рамки допустимого. Какой же из сервисов станет добропорядочным жителем вашей системы? Какими возможностями он должен обладать, чтобы гарантировать управляемость системы, и то, что один негодный сервис не приведет к сбою всей системы? Ведь здесь как с людьми: добропорядочность жителя в одних условиях не определяет то, на что он может стать похож в каких-либо других условиях. И тем не менее есть некие общие характеристики подходящих сервисов, которых, на мой взгляд, очень важно придерживаться. Существует ряд ключевых областей, в которых допустимость слишком больших отклонений может привести к весьма жарким временам. Согласно определению Бена Кристенсена (Ben Christensen) из компании Netflix, когда мы мысленно рисуем себе крупную картину, «должна быть стройная система из множества мелких деталей с автономными жизненными циклами, способная представлять собой единое целое». Следовательно, нужно найти разумный баланс оптимизации автономии отдельно взятого микросервиса, не теряя при этом из виду общую картину.
Рис. 2.1. Практический пример принципов и инструкций
Одним из способов выявления сути такого баланса является определение четких признаков, наличие которых обязательно для каждого сервиса.
Очень важно иметь возможность составить логически последовательное, распространяемое на все сервисы представление о работоспособности системы. Это представление должно быть общесистемным, а не специфичным для конкретного сервиса. Конечно, в главе 8 будет определено, что быть в курсе работоспособности отдельного сервиса также немаловажно, но зачастую только при попытке диагностировать более широкую проблему или разобраться в более крупной тенденции. Чтобы максимально облегчить задачу, я хотел бы предложить использование однообразных критериев работоспособности и общих отслеживаемых параметров.
Можно выбрать применение механизма активной доставки данных, при котором каждому сервису нужно доставлять данные в центр. Для метрик это может быть Graphite, а для отслеживания работоспособности — Nagios. Или можно принять решение об использовании систем опроса, самостоятельно собирающих данные из узлов. Внутри приемника технологию нужно сделать непрозрачной и не требующей от ваших систем мониторинга изменений с целью ее поддержки. Журналирование здесь входит в ту же категорию: оно должно осуществляться в одном месте.