Многим казалось, что подобная асинхронная коммуникация намного эффективнее. Один из тех людей, с кем я общался в ходе своего исследования, сравнил синхронную коммуникацию (те виды общения, когда вам нужно беседовать с другими людьми) с устаревшими бизнес-технологиями вроде факса. Он написал, что это древнее ископаемое «позабавит ваших внуков», когда вы будете вспоминать, как люди работали раньше[89].
Однако проблема в том, что электронная почта не стала волшебной палочкой, способной повысить продуктивность. Выяснилось, что короткое послание не всегда способно заменить непродолжительный телефонный разговор. Для установления контакта сотрудники иногда отправляют десятки неоднозначных сообщений. Если вы помножите те многочисленные взаимодействия в реальном времени, которые были раньше, на несметное количество текстовых сообщений, станет понятно, почему сотрудники, занимающиеся научной работой, в среднем отправляют и получают по 126 писем в день[90].
Однако не всех удивило, что затянувшая коммуникация усложнила жизнь. Когда в современный деловой мир пришла электронная почта, ученые, занимающиеся теорией распределенных систем (раздел информатики, которому я уделяю внимание в своей научно-исследовательской работе), наряду с прочими вопросами начали изучать плюсы и минусы синхронного и асинхронного общения. Как это бывает, выводы, к которым они пришли, были совершенно противоположны тому мнению, которое сложилось у сотрудников.
Сравнение синхронной и асинхронной коммуникации лежит в основе информатики. В первые двадцать лет компьютерной революции программисты создавали продукты, которые должны были работать на одном компьютере. Позже, с развитием компьютерных сетей, стали писать программы, которые можно запускать на нескольких машинах и работать совместно при помощи сети. Так возникли распределенные вычислительные системы. Когда ученые начали выяснять, как скоординировать работу компьютеров, составляющих сеть, они взвесили все плюсы и минусы разных видов коммуникации.
По умолчанию компьютеры, связанные между собой в единую сеть, работают асинхронно. Пользователь за машиной А посылает сообщение пользователю за машиной Б в надежде, что оно будет прочитано и обработано. Но пользователь за машиной А не знает, сколько потребуется времени пользователю за машиной Б, чтобы прочесть сообщение. Быстрота взаимодействия зависит от многих факторов. Например, компьютеры могут работать с разной скоростью. Если на машине Б запущены и другие процессы, может пройти определенное время, пока она проверит, есть ли входящие сообщения. Случаются и непредсказуемые сетевые задержки и поломки оборудования.
Написание алгоритмов для работы распределенных систем оказалось куда более сложной задачей, чем изначально полагали многие специалисты. Например, весьма впечатляющее научное открытие в области информатики, относящееся к этому периоду, — так называемая проблема консенсуса.
Представьте, например, что каждый компьютер в распределенной сети начинает какую-то операцию — например, пользователь производит транзакцию. Машина должна решить, продолжать операцию или прекратить ее. Для этого компьютеру нужно получить согласие других машин — все они должны проголосовать за продолжение или отмену операции.
Самое простое решение, чтобы понять, какой вариант выбрать, — собрать данные с других компьютеров и применить некое правило, например посчитать голоса, чтобы определить предпочтительное решение. Если все машины получают одинаковое количество голосов, они все принимают одно и то же решение. Проблема заключается в том, что компьютер может выйти из строя и не успеть проголосовать. Если такое случается, все остальные компьютеры в сети будут вечно ждать голоса своего «напарника», который перестал функционировать. Поскольку в асинхронной системе срок ожидания не обозначен четко, ожидающие ответа компьютеры не знают, когда прекращать ждать и продолжать оперировать уже имеющимися голосами.
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
Для начала инженеры, которые изучали эту проблему, предложили очевидное решение. Вместо того чтобы ждать ответа от всех машин, достаточно будет получить обратную связь от большинства из них. Представьте, например, что действует такое правило: если большинство устройств посылают сигнал «продолжить», компьютер, отправивший запрос, тоже решает продолжать. В противном случае он отменяет операцию — на всякий случай. На первый взгляд, правило может способствовать консенсусу — до тех пор, пока отказывает лишь небольшое число машин. Однако, к удивлению многих специалистов этой области, в работе, опубликованной в 1985 году, трое ученых-информатиков — Майкл Фишер, Нэнси Линч (мой научный руководитель в аспирантуре) и Майкл Патерсон, — виртуозно оперируя математической логикой, доказали, что нет такого алгоритма для асинхронной распределенной системы, который мог бы гарантировать, что консенсус будет достигнут всегда, даже если есть уверенность, что из строя может выйти максимум один компьютер[91].
Не буду утомлять вас техническими деталями[92], но становится понятно, как работает алгоритм консенсуса в распределенных системах. Ясно, что в асинхронных системах сложно обеспечить координацию действий, поэтому практически всегда требуются дополнительные затраты, чтобы превратить их в синхронные. Что касается распределенных систем, исследование, проведенное по следам знаменитой работы 1985 года, предложило несколько вариантов синхронизации. Одно из кардинальных решений (например, они используются в системах электродистанционного управления и в работе устойчивого к сбоям оборудования для транзакций кредитных карт) — соединить все компьютеры в общую электрическую сеть, чтобы они работали с одинаковой скоростью. Такой подход поможет избежать непредвиденных задержек при ожидании ответа и позволит оборудованию сразу определить, вышел ли компьютер из строя.
Поскольку создать единую электрическую сеть иногда сложно, популярным решением для превращения систем в синхронные стало специальное программное обеспечение. Оказалось, что, максимально эффективно используя знания о задержках при передаче сообщений и скорости работы процессоров, можно написать программы, которые способны сделать коммуникацию стабильной или смоделировать поведение надежных машин и помочь синхронизировать работу ненадежных станций в системе.
В начале интернет-эры борьба с асинхронностью играла решающую роль, и предложенные варианты в числе прочего помогли управлять огромными базами данных таких компаний, как Amazon и Google. В 2013 году Лесли Лэмпорт, главная фигура в области распределенных систем, получил премию Тьюринга — самую престижную награду в области информатики — за разработку алгоритмов для синхронизации распределенных систем[93].
В этой технической информации о синхронной и асинхронной коммуникации меня поражает то, что она кардинально отличается от представлений деловых людей, которые энергично пытаются решить те же проблемы на своем рабочем месте. Как мы уже знаем, руководители сосредоточились на тех трудозатратах, которых требует синхронная коммуникация, например когда вы не можете до кого-то дозвониться или вам нужно ехать на лифте на другой этаж, чтобы побеседовать с нужным сотрудником. Они были уверены, что если им удастся избежать этих дополнительных трудозатрат с помощью инструмента, подобного электронной почте, то взаимодействие станет более эффективным. Однако ученые-информатики пришли к противоположным выводам. Исследуя асинхронную коммуникацию с точки зрения теории алгоритмов, они обнаружили, что взаимодействие с непредвиденными задержками приводит к возникновению новых проблем. В то время как деловые люди рассматривали синхронность как препятствие, которое нужно преодолеть, специалисты в области вычислительной техники начали понимать, что это необходимый элемент для эффективного взаимодействия.
