Якось я спостерігав, як інтернет-магазин невеликої компанії перестав приймати замовлення через те, що на іншому кінці планети сервіс, який визначав країну відвідувача за адресою, оновив формат відповіді. Магазин не продавав за кордон. Країна відвідувача йому, загалом, була не потрібна. Але колись давно розробник підключив цю перевірку «про всяк випадок», і тепер від неї залежала сторінка оформлення замовлення. Ніхто з працівників компанії навіть не знав про існування цього сервісу. Дізналися, коли продажі зупинилися. Я часто згадую цю історію, коли говорю про складність сучасного світу.
Ефект метелика перестав бути метафорою
Науковець, який вигадав образ метелика, помах крил якого спричиняє ураган на іншому континенті, говорив про погоду. Але сьогодні цей образ описує майже будь-яку технологічну систему. Ваша облікова програма залежить від бібліотек, які написали тисячі незнайомих людей. Ваш сайт залежить від хостингу, від служби доменних імен, від платіжного шлюзу, від сервісу розсилок, від браузерів, які оновлюються без Вашої згоди. Кожна з цих ланок, своєю чергою, залежить від десятків інших.
І це не лише про техніку. Бізнес влаштований так само. Постачальник затримав одну деталь, і став цілий цех. Змінилися правила на маркетплейсі, і впали продажі в трьох регіонах. Пішов один ключовий працівник, і перестали працювати процеси, про які всі думали, що вони працюють самі. Світ складається зі складників, повʼязаних один з одним значно щільніше, ніж це видно на схемах.
Чому складність не можна скасувати
Перша реакція багатьох керівників на такі історії: давайте все спростимо, приберемо зайві звʼязки, робитимемо все самі. Це зрозуміле бажання, але наївне. Відмовитися від зовнішніх звʼязків означає збудувати фортецю, яка все виробляє сама, і програти тим, хто користується готовими сервісами й витрачає сили на головне. Складність не помилка, яку можна виправити. Це ціна, яку ми платимо за можливості. Що більше звʼязків має система, то більше вона вміє, і то більше в неї точок, де щось може піти не так.
Отже, питання не в тому, як позбутися складності, а в тому, як жити з нею так, щоб локальний збій не перетворювався на катастрофу. І тут інженерам є чого повчитися в природи й історії.
Уроки корабелів
Кораблі давно будують із водонепроникними перегородками. Корпус поділений на відсіки, і якщо пробоїна затопила один, решта тримає судно на плаву. Це рішення зʼявилося не з любові до складності, а з гіркого досвіду: корабель без перегородок тоне від однієї дірки. Саме цей принцип лежить в основі стійких програмних систем.
Добра система не та, у якій нічого не ламається. Добра система та, у якій поломка однієї частини не топить усі інші.
На практиці це означає кілька простих правил, які ми застосовуємо в проєктах:
- ізоляція модулів: каталог, замовлення, склад, оплата влаштовані так, щоб збій в одному не зупиняв інших; якщо впав модуль рекомендацій, покупець однаково може оформити замовлення;
- захист від зовнішніх збоїв: якщо сторонній сервіс не відповідає, система не чекає його нескінченно, а за короткий час переходить до запасного сценарію або показує зрозуміле повідомлення;
- необовʼязкове лишається необовʼязковим: перевірка, без якої можна обійтися, не має блокувати критичний процес, як в історії з визначенням країни;
- спостережуваність: система сама повідомляє, де в неї болить, перш ніж це помітять клієнти.
Бачити звʼязки, перш ніж вони обірвуться
Найнебезпечніше в складних системах це невидимі звʼязки. Ті, про які ніхто не памʼятає, які зʼявилися колись із випадкової причини й тихо живуть роками. Тому одна з найважливіших частин роботи архітектора не стільки вигадувати нове, скільки робити видимим наявне. Намалювати мапу: що від чого залежить, які зовнішні сервіси використовуються, де проходять дані, який процес зламається, якщо зникне ось ця ланка.
Я регулярно пропоную клієнтам просту вправу: виписати всі зовнішні сервіси й усіх людей, без яких їхній бізнес зупиниться хоча б на день. Майже завжди список виходить довшим, ніж очікували, і майже завжди в ньому є кілька пунктів, про які керівник дізнався вперше. Це неприємно, але значно приємніше, ніж дізнатися про них у момент збою.
Що робити з цим знанням
Світ не стане простішим. Він ставатиме лише складнішим і звʼязнішим, і, чесно кажучи, мені це подобається: у цьому багато краси й можливостей. Але керувати компанією в такому світі можна лише одним способом: приймати складність як даність і будувати системи, готові до неї. Ділити на відсіки. Знати свої залежності. Мати запасні сценарії для найважливішого. І не підключати «про всяк випадок» те, без чого можна обійтися.
У Systems ми починаємо будь-яку архітектуру з мапи звʼязків, а модульність закладаємо у фундамент, а не прикручуємо потім. Fractal у цьому допомагає, бо система описується як набір моделей з явними звʼязками, і невидимим залежностям у ній просто ніде сховатися. Метелики махатимуть крилами завжди. Наше завдання зробити так, щоб у Вас від цього не починався ураган.
