Два мира в ИТ: мир «не трогай» и мир «трогай по расписанию»
Для ЛЛ: хаос инжиниринг – вещь в себе
Для начала немного классики
"Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?
Программист: ну представь, что ты писатель и поддерживаешь проект “Война и мир”. У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь “шёл дождь”, сохраняешь, вылетает сообщение об ошибке “Наташа Ростова умерла, продолжение невозможно”. Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение “Поручик Ржевский умер.” Выясняется, что он в следующей главе облокачивается о столб, которого уже нет..."
rol_foster: Сегодня полдня искали ошибку, из-за которой, образно говоря, у Наташи при прогулке с Пьером падают трусы. Одна из функций программы делает то, что делать не должна. Откатили на вчера - трусы на месте. Перелопатили весь код обновления, там вообще ни трусов, ни Наташи, ни даже Ржевского, тупо красят дом Болконских. Чуть ли не пошагово разбираем - все нормально. Но трусы падают. И, чтобы найти причину, придется перелопатить весь код, а это недели две минимум.
В общем, начальник задумчиво посмотрел на девушку и волевым решением выдал Наташе подтяжки.
Теперь чуть ближе к теме
Случайно посмотрел ролик про «мутационное тестирование кода», и про последующее покрытие юнит тестами. Дело нужное, дело полезное, позволяет понять, насколько твой код вообще покрывается тестированием.
Попутно вспомнил про «хаос инжинеринг». Подход тот же – давайте что-то сломаем, и посмотрим, отреагирует ли система мониторинга, как поведет себя система, и так далее. Всегда было очень полезно.
Cледом прилетел ролик про работу в сложных системах электротехники. Где у тебя проводка идет не по схеме, непонятно куда, непонятно почему, и вообще вся система представляет собой сплошные сопли, которые трассировать можно, но не очень нужно. Потому что работает, и прибыль приносит, а переборка означает возможный простой, причем для всего цеха.
Так бывает. Про «провода куда-то туда» и промышленную археологию есть много статей, «так вот почему было сделано именно так». У знакомых именно так электрики обесточили половину завода – просто отключили провода, которые шли куда-то туда. Шли не по их плану. Повезло, потому что могло и взорваться.
В некоторых системах, действительно, система работает в стационарном (установившемся) режиме, и выводить ее за границы локального оптимума может быть чревато.
Есть и другая сторона медали.
Существует два вида ремонта – по фактическому износу и по времени, то есть планово-предупредительный. Вскоре в РФ опять начнется зимний сезон, и многие внезапно для себя обнаружат, что лысая летняя резина очень плохо влияет на управляемость в добротный осенний гололед. Но это опять никого не остановит от того, чтобы собрать пробку перед мостом.
Плановая замена многим не приходит в голову.
Все вышеперечисленное происходит и в ИТ.
У одних есть понимание, что в их системе работают люди. Что люди уязвимы, и могут запустить что-то не то. Что уязвимости существуют, и системы не стабильны. Что лучше сломать систему «по расписанию». Что надо заменить систему планово, до того как она сломается совсем.
У других лысые летние шины отлично работают до внезапного прихода зимы. И какие-то нехорошие люди ставят столб именно там, куда почему-то едет машина, которая все лето отлично ездила мимо него. И почему то потом, после ремонта машины, снова нет денег на новую резину.
Это один мир, и он понятен, я сам ленив.
Есть отдельный удивительный мир СПО сектантов, которым враги, в виде злых капиталистических корпораций, тыкают носом в то, что в код СПО с момента его создания, то есть 30+ лет, никто не смотрел. Главное знать, что все, кто не согласен с безусловной идеальностью СПО – враги.
Не код плохой, а капиталисты, не перепутайте. Не резина лысая, а столб вкопали не там.
Не СПО сектант сам не смотрел в код, а какие-то другие СПО сектанты. Не он.
Особенно хорошо это совмещается с ленью обыкновенной. Лень плюс вера.
Подводя итог
Чем-то ситуация в ИТ напоминает ситуацию с Бургер кингом и недавним скандалом. Когда и руководство не контролировало ситуацию, и персонал творил дичь.
Но еще больше это напоминает ситуацию с Бургер Кингом, когда работники франчайзи начали обращаться к бывшему директору, но не директору своего производства, а бывшему директору даже не головного производства, а сети франчайзи, с словами «нас то за что».
Тот же процесс, «меня то за что», часто происходит и в ИТ. И происходит именно по сценарию выше. Производитель (в том числе СПО) выпускает обновление (зимнюю резину). Производитель выпускает оповещение – скоро зима.
Сектант не считает нужным применять обновление и, внезапно для него, у него на привыччной дороге возникает столб.
Кто виноват у сектанта? Столб.
Кто виноват в том, что это произошло, с точки зрения бизнеса? Тот, кому платили деньги, чтобы такого не происходило.
Кто будет виноват у сектанта? Конечно, капитализм и проприетарное ПО. И бизнес. Кто угодно. Не сектант.
В чем-то такая позиция сходна с позицией ленивого HR, у которого всегда виноваты слишком жадные кадры.
Заключение
Отсеивать СПО сектантов уже давно не сложно. ИИ напишет кому угодно прекрасное резюме.
Но достаточно 1-2 вопросов, и дальше разговор идет уже только из вежливости.
Отсеивать будущих лентяев, которые еще и постараются скрыть проблему, сложнее. Для этого есть испытательный срок, оценки 365, и массово практикуемые "голодные игры". Когда самого неприятного сьедают остальные
Огромную проблему стал представлять вайб кодинг. Когда люди не могут понять, что им написало ИИ, и почему. Но ИИ нужен, без него сложнее. Но нужен очень и очень ограниченно.
В РФ этого пока мало заметно, в остальном мире с этим просто караул. Но я про это отдельно напишу. Наверное. Потом.
