Реальність мережевого інженера (з локшиною та… сіллю?)
Останнім часом, обговорюючи з інженерами різні інциденти, я помітив цікаву закономірність.
У цих обговореннях незмінно виникає питання «першопричини». Вірні читачі, напевно, знають, що в мене є по . У багатьох організаціях аналіз інцидентів повністю ґрунтується на цій концепції. Вони використовують різні техніки виявлення причинно-наслідкових зв'язків, такі як . Ці методи припускають так звану «лінійність подій» як незаперечну догму.
Коли ви ставите під сумнів цю ідею і вказуєте на те, що в складних системах лінійність заспокійливо оманлива, то народжується захоплююча дискусія. Сперечальники пристрасно наполягають, що тільки знання «першопричини» дозволяє зрозуміти те, що відбувається.
Я помітив цікаву закономірність: розробники та девопси по-різному реагують на цю ідею. На мій досвід, розробники частіше стверджують, що причина має значення і що в подіях завжди можна встановити причинно-наслідкові зв'язки. З іншого боку, девопси найчастіше погоджуються, що складний світ не завжди підкоряється лінійності.
Я завжди запитував себе, чому так? Що змушує програмістів так критикувати ідею першопричина — міф? Немов імунну систему, яка розпізнає стороннього агента. Чому вони так реагують, тоді як девопси швидше схильні розглянути цю ідею?
Я не зовсім впевнений, але є міркування щодо цього. Воно пов'язані з різними контекстами, у яких професіонали виконують повсякденну роботу.
Розробники часто працюють із детермінованими інструментами. Звичайно, компілятори, компонувальники, операційні системи — все це складні системи, але ми звикли, що вони дають детермінований результат, і представляємо їх саме детермінованими: якщо надати одні й ті самі вхідні дані, то ми зазвичай очікуємо від цих систем одну й ту саму видачу . І якщо з видачею проблема («баг»), то розробники вирішують її за допомогою аналізу вхідних даних (або від користувача, або від набору інструментів у процесі розробки). Вони шукають помилку, а потім змінюють вхідні дані. Це виправляє "баг".
Основне припущення розробки програмного забезпечення: одні й самі вхідні дані надійно і детерміновано дають однакову видачу
Фактично, недетермінований результат сам собою вважається помилкою: якщо несподіваний чи помилковий висновок не відтворюється, то розробники прагнуть розширити дослідження інші частини стека (операційна система, мережу тощо. буд.), які теж ведуть себе більш-менш детерміновано, видаючи однаковий результат при однакових вхідних даних… та якщо це не так, то це все одно вважається багом. Просто тепер це баг операційної системи чи мережі.
У будь-якому разі, детермінізм - це базове, практично само собою зрозуміле припущення для більшої частини роботи, яку роблять програмісти.
Але для будь-якого девопса, який провів день, збираючи залізо у стійки або розбираючись з хмарним API, ідея повністю детермінованого світу (доки взагалі є можливість відобразити всі вхідні дані!) — у кращому разі, скороминуще поняття. Навіть якщо відкинути убік , досвідчені інженери бачили у цьому світі найдивніші речі. Вони знають, що , не кажучи про мільйони інших факторів у навколишньому середовищі
Так що досвідченим інженерам простіше засумніватися, що у всіх інцидентів є єдина причина, а техніки на кшталт «П'ять чому» правильно (і повторювано!) приведуть до цієї причини. По суті, це суперечить їхньому власному досвіду, коли шматочки головоломки на практиці не складаються настільки чітко. Тому вони легше сприймають цю ідею.
Звичайно, я не кажу, що розробники наївні, дурні чи нездатні зрозуміти, наскільки лінійність може бути оманлива.
Але мені здається, що звичайна реакція від розробників у цих суперечках часто пов'язана з тим фактом, що концепція детермінізму загалом добре служить їм у повсякденній роботі. Вони стикаються з недетермінізмом не так часто, як інженерам доводиться ловити котів Шредінгера на своїй інфраструктурі.
Може, це не повністю пояснює реакції розробників, але це потужне нагадування, що наші реакції є складною сумішшю з багатьох факторів.
Важливо пам'ятати про цю складність, незалежно від того, ми розбираємо один інцидент або співпрацюємо на конвеєрі доставки програмного забезпечення, або намагаємося осмислити ширший світ.
Джерело: habr.com