Рис. 10.1. Общее представление о структуре организации Realestate.com.au и ее команд, а также об увязке с архитектурой
Эта структура позволяет добиться высокой автономности не только команд, но и различных частей бизнеса. Начав с совсем небольшого количества сервисов несколько лет назад, REA теперь обладает сотнями сервисов, количество которых превышает количество сотрудников и растет высокими темпами. Возможность поставки изменений помогла компании добиться значительных успехов как на местном рынке, так и за рубежом. И что отраднее всего, из разговоров с людьми я вынес впечатление, что существующее состояние как архитектуры, так и организационной структуры сформировалось благодаря самым последним шагам на этом пути, но никак не достижению конечного пункта назначения. Я полагаю, что в ближайшие пять лет облик REA снова претерпит существенные изменения.
Организации с адаптивностью, достаточной для изменения не только системной архитектуры, но и организационной структуры, могут получить огромные преимущества в сфере повышения автономности команд и сокращения времени вывода на рынок новых свойств и функциональных возможностей. REA не пребывает в вакууме, а является одной из множества организаций, реализующих подобную системную архитектуру.
До сих пор речь шла о том, как организационная структура влияет на устройство системы. А как насчет обратного влияния? То есть может ли устройство системы изменить организацию? Несмотря на то что я не смог найти столь же убедительных доказательств идеи о том, что закон Конвея работает и в обратном порядке, периодически мне приходилось сталкиваться с этим явлением.
Наверное, наилучшим примером был клиент, с которым я работал много лет назад. В те дни, когда Всемирная сеть только зарождалась, а Интернет воспринимался как нечто поступающее на гибком диске компании AOL через входную дверь, эта компания представляла собой довольно солидную издательскую фирму, у которой был небольшой, весьма скромный сайт. Это был сайт ради сайта, и, по большому счету, порядок, в котором работал бизнес, был совершенно неважен. Когда была создана исходная схема, порядок работы системы строился на весьма произвольных технических решениях.
Содержимое для этой системы обеспечивалось несколькими способами, но основная часть поступала от третьих лиц, размещавших объявления для всеобщего обозрения. Была система ввода информации, позволявшая третьим лицам за плату создавать содержимое, центральная система, получавшая данные и улучшавшая их различными способами, и система вывода, формировавшая окончательный вид сайта.
Вопрос о том, были ли исходные конструкторские решения правильными на то время, мы оставим для историков, но за многие годы в компании не происходило существенных изменений, и я и многие мои коллеги удивились бы, если бы устройство системы подошло для нынешнего состояния компании. Физический печатный бизнес организации существенно сократился, а преобладают доходы и, следовательно, бизнес-операции из интернет-сферы.
Все это время мы наблюдали, как организация четко подстроилась под систему, разработанную сторонними специалистами. Три канала или подразделения, присутствовавшие в IT-сфере бизнеса, были увязаны с каждой из сторон бизнеса: вводом, ядром и выводом. Внутри каналов были выделены команды поставки. В то время я не понял, что эти организационные структуры не предшествовали устройству системы, а фактически сформировались вокруг этого устройства. По мере сокращения физической стороны бизнеса и роста его цифровой стороны устройство системы ненароком указало путь роста самой организации.
В итоге мы поняли, что, несмотря на имеющиеся недостатки в устройстве системы, для перехода в новое качество понадобилось внесение изменений в структуру организации. Сколько лет прошло, а этот процесс все еще не завершен!
Неважно, как это выглядит на первый взгляд, но проблема всегда в людях.
Следует признать, что в среде микросервисов разработчику труднее думается о написании кода в собственной ограниченной области. Он должен больше вникать в последствия вызовов, пересекающих границы сетей, или последствия сбоев. Мы также говорили о том, что с микросервисами проще испытывать применение новых технологий — от хранения данных до языков программирования. Но для тех, кто попал в мир микросервисов из мира монолитных систем, где большинству разработчиков приходится использовать один язык, совершенно не обращая внимания на оперативные интересы, такое положение вещей может стать толчком к внезапному пробуждению.
Точно так же может стать обременительным принуждение команд разработчиков к повышению автономности. Люди, которые в прошлом перебрасывали свою работу кому-то еще через забор, привыкли выдвигать обвинения в чужой адрес и не могут почувствовать себя комфортно, когда несут за свою работу полную ответственность. Могут быть даже выработаны условия контракта, предписывающие вашим разработчикам ношение приборов оперативного оповещения о сбоях в работе систем, которые они поддерживают!
Хотя эта книга посвящена в основном решению технологических вопросов, людей нельзя сбрасывать со счетов, ведь речь идет о людях, которые создали то, чем вы пользуетесь сейчас, и создают все, что будет применяться в дальнейшем. Если придумывать, как все должно делаться, без учета мнения персонала или людских возможностей, то это, скорее всего, не приведет ни к чему хорошему.
Что касается данной темы, то у каждой организации имеется свой ход развития. Нужно понимать, насколько ваш персонал готов к изменениям. Не нужно их подталкивать сверх всякой меры! Вероятно, на короткий период времени у вас по-прежнему будет отдельная команда, занимающаяся поддержкой клиентов или разработкой, что даст разработчикам время на то, чтобы подстроиться под новые инструкции. Возможно, придется смириться с тем, что для выполнения всей этой работы потребуются люди различных наклонностей. При любом подходе нужно понимать, что в мире микросервисов следует четко определять зоны ответственности людей, а также понимать, почему именно такие зоны ответственности играют для вас важную роль. Это может помочь вам заметить возможные квалификационные пробелы и подумать о том, как их заполнить. Для многих людей это путешествие станет весьма непростым. Всегда нужно помнить о том, что без людей, с которыми вы работаете, любые изменения, которые захочется внести, с самого начала могут быть обречены на провал.
Закон Конвея подчеркивает опасности попыток навязывания моделей систем, не соответствующих структуре организации. Он подводит нас к стремлению закрепить владение микросервисами за командами, расположенными в одном месте, которые, в свою очередь, выстраиваются вокруг соответствующих ограниченных контекстов, существующих в организации. Если такая двойная увязка отсутствует, мы получаем точки напряженности, рассмотренные в данной главе. Признавая связь между этими двумя понятиями, мы сможем гарантировать наличие смысла создаваемой нами системы для заказавшей ее организации.
Часть рассмотренных здесь вопросов имела отношение к сложностям работы с расширяющимися организациями. Но есть и другие требующие рассмотрения технические вопросы, которыми следует заняться, когда системы начинают расширяться, выходя за рамки нескольких обособленных сервисов. К их рассмотрению мы приступим в следующей главе.
11. Масштабирование микросервисов
Когда работаешь с изящными небольшими примерами форматом с книжную страницу, все кажется простым. Но реальный мир намного сложнее. Что будет, когда наши архитектуры микросервисов станут расширяться и превращаться из простых и скромных в нечто более сложное? Что будет, когда нам придется справляться со сбоями нескольких отдельных сервисов или управлять сотнями сервисов? Какие схемы нужно будет скопировать, когда микросервисов у вас станет больше, чем людей? Давайте все это выясним.
Мы понимаем, что нештатных ситуаций не избежать. Может отказать жесткий диск. Может дать сбой наша программа. И все, кто читал об ошибках, происходящих при распределенном вычислении, могут сказать о том, что знают о ненадежности сети. Мы можем приложить максимум усилий, пытаясь ограничить число сбоев, но при определенном масштабе сбои становятся неизбежными. Жесткие диски, к примеру, сейчас надежнее, чем когда-либо прежде, но временами и они выходят из строя. Чем больше у вас жестких дисков, тем выше вероятность отказа для отдельной стойки; при расширении масштаба отказ становится статистически неизбежен.
Даже тем из нас, кто не собирается слишком сильно расширять свою систему, все же стоит учитывать возможность сбоев. Если мы, к примеру, можем изящно обрабатывать сбои сервиса, то у нас получится и обновлять службу на месте, поскольку иметь дело с запланированными отключениями намного проще, чем с незапланированными.
Мы также сможем тратить немного меньше времени на попытки остановить неизбежное и уделять немного больше времени на то, чтобы справиться с ними как можно изящнее. Меня удивляет, что немалое количество организаций тратят силы и средства в первую очередь на попытки предотвращения сбоев и значительно меньше усилий направляют на упрощение восстановления после них.
Предположение о том, что все может дать сбой и неизбежно его даст, заставит изменить представление о том, как решать проблемы.
Я видел пример такого мышления, когда много лет назад был в кампусе Google. В приемной одного из зданий в Маунтин-вью в качестве своего рода экспозиции стояла старая стойка с машинами. И там я кое-что заприметил. Эти серверы были без кожухов — голые материнские платы, вставленные в стойку. Но мне бросилось в глаза то, что жесткие диски были смонтированы на липучках. Я спросил одного из сотрудников Google о том, почему так сделано. Он ответил, что жесткие диски настолько часто выходят из строя, что им не захот