воскресенье, 21 июля 2024 г.

Актуалочка про недавний сбой

 Немного хочу написать тупое и очевидное про недавний сами-знаете-какой сбой. Вообще, далёкие от техники люди успели раскрутить целую конспирологию вокруг, на самом деле, дурацкого случая. Потому, что если посмотреть, это скорее следствие деградации способности к управлению и общего похуизма (нет, я не назову это пофигизмом, уж извините за мат, это именно он самый).

Потому что рассмотрим ситуацию с трёх сторон - разработка, деплой и со стороны условных админов клиентов. Что здесь не так?

Со стороны разработки - вообще в разработке условные изменения проходят как минимум через code-review и QA. Т.е. если действительно было NPE, то в процессе анализа (статического и ручками) оно должно было отловиться. Ну и по нормальному для таких серьёзных вещей уже есть автотесты, которые получается оно прошло, непонятно как.  Ну ок, но получается что оно ещё и ручное QA как-то прошло. Получается странновато - либо это не делалось, либо это какой-то очень редкий случай (мягко говоря, сомнительно, учитывая объём падений). Т.е. либо тут не были соблюдены процессы (деплоим по-быстрому, а там кривая вывезет), либо они вообще не делались - и тогда это жесть, mission-critical системы, которые разрабатываются как попало - это никуда не годится.

Почему я верю, что такое возможно? Потому что пресловутая ОПТИМИЗАЦИЯ, когда хочется сэкономить на всём - на разрабах, процессах и вообще, вон конкуренты нас опережают, надо бы ПОБЫСТРЕЕ. Чёрт, у меня до сих пор валяется черновик поста про историю, где один гений держал мастер-ветку в репозитории крупного продукта сломанной три недели, тормозя важные процессы разработки и отладки! Три недели! И это были не условные "Рога и копыта", а крупная зарубежная фирма.

Со стороны деплоя тут тоже не всё гладко. Ну уже давно известно, что вообще-то, по-нормальному, обновления надо раскатывать сначала на условные k машин, проверять баги, и так дальше наращивать число обновлённых машин. Потому что если раскатить на все обновления чего-то mission-critical, то поломка будет... Правильно везде! Почему эти практики не выполняются? Ну потому что это... сложно. Надо возиться, думать, обеспечивать обратную совместимость. Есть ощущение, что это не хочется по причинам выше.

Ну ладно, ок, разработка лажает, бывает. Но со стороны админства клиентов, это вообще какой-то цирк. Я хз, я человек успевший поглазеть на старый линукс, да и на винду. И, блин, я лишь недавно стал более-менее доверять апдейтам винды и линукса. Потому что они перестали чаще всего что-то фатально ломать чаще всего. И тут получается: mission-critical машины смотрят в интернет и апдейты на них накатываются автоматом. Как по мне, в такой момент, инфобезопасники должны хвататься за голову - где-нибудь на роутерах может сидеть зловещий "Мэллори", который через эксплойты DNS и прошивок роутера подменяет апдейт и получает доступ к критической инфраструктуре. Чёрт, ну нельзя чтобы апдейты в таких случаях накатывались автоматом. Да, это некрасиво и неудобно - накатывать на одну машину, смотреть что пошло не так, а потом уже обновлять все. Но опять же, если это mission-critical на этом экономить нельзя. Но опять же, к чёрту стабильность, надо стрелять себе в голову.

С позиции абстрактного - ясно, что мы уже давно упёрлись в разработке ПО в страшную сложность того, что делается и что с чем стыкуется. Как по мне, на смену "быстрой разработке" должна наконец прийти медленная. Но этого мы походу не дождёмся, пока вот такие истории не станут обыденностью. А там глядишь, кто-то и вовсе начнёт выигрывать за счёт рационального использования старых способов.

В общем, ждём такого ещё. Я, на самом деле, сомневаюсь, что какие-то серьёзные выводы будут сделаны. А вот наказать и уволить - да, пожалуй сделают, но системного решения не будет. 

Комментариев нет:

Отправить комментарий