Дякую!

текст англійською:

===
To whom it may concern:

SaveLife.In.UA is a well-known and established Ukrainian NGO. By blocking it’s account and freezing the funds you’re playing directly into Putin’s hands.

I do hope that it is just a misunderstanding and you will unblock the account and unfreeze the funds soon — I don’t want to think that it is a malicious action. Trying to hurt Ukrainian NGOs in the middle of Putin’s aggression doesn’t look good at all. I really, really hope that it is a mistake that you will rectify soon.

Sincerely,
xxxx
===

Я зараз відкрию страшну таємницю. На відміну від СРСР (де будь-хто, хто залишив країну — вважався зрадником і мусив рвати усі зв’язки з батьківщиною) — в сучасному світі можна виїхати в іншу країну, попрацювати, повернутися та відкрити бізнес вдома, знову поїхати і так далі, поки не помреш. :)

А мірятися патріотизмом — це дуже дивна ідея.

Good point, спасибо!

Спасибо за фидбек!

Насколько я помню — оно ж все равно не покажет содержимое процессов, не принадлежащих текущему аккаунту?

все так, I stand corrected

Тут есть несколько подходов:

1) заранее подготовленные стандартные модули-кирпичики с лучшими практиками, которые разработчик может использовать просто из коробки.

(Собственно, они заслуживают отдельной статьи, потому что они нужны как минимум для того, чтобы уменьшить когнитивную нагрузку на разработчика — без них многих разработчиков просто перегрузит сложность работы с инфраструктурой)

2) код-ревью — если мы описываем инфраструктуру как код, то нам не помешает и стандартная практика код-ревью, где эксперт сможет поймать явный косяк.

3) автоматизированное тестирование инфраструктуры — тут уже говорили про сканирование и аудит конфигураций, но в целом это опять же, интересная тема, заслуживающая отдельного разговора.

то власна інфраструктура тих «хмар» — теж вчорашній день? :-)

В тих хмар є свої інструменти автоматизації, які нам, простим смертним, не дуже доступні, якщо ми працюємо не в Гуглі, Фейсбуці або Амазоні.

Але автоматизація приватних хмар — це дуже цікава проблема. Тут (я буду чесним) в мене нема якогось простого рецепту.

Отличный вопрос. Я не стал углубляться в детали полной автоматизации — но без полного автоматического тестирования инфраструктуры избавиться от вмешательства человека не получится.

Поэтому короткий ответ — так, самый простой вариант это как минимум получить подтверждение от человека (как минимум, когда речь идет о production deployment).

Длинный ответ — полностью автоматизированный пайплайн требует:

1) полностью автоматизированного тестирования
2) полностью автоматизированного роллбека — один из вариантов тут может быть green/blue deployment, при котором два environment (новый и старый) какое-то время существуют одновременно, траффик перенаправляется от старого к новому, мониторятся метрики, и при сбое — траффик перенаправляется обратно.

Однако это нетривиальная задача — тут нужно управлять траффиком, иметь копии двух environments одновременно (что может быть недешево), управлять stateful services отдельно — потому что иначе придется дуплицировать не только инфраструктуру как таковую, но и данные, а это опять же совсем нетривиально. В большинстве случаев такой подход просто не окупает инвестиций.

Все так, Вы поднимаете правильные моменты — в частности, про модули, без которых когнитивная нагрузка на разработчика становится неприлично велика. Однако, Вы верно заметили, что статью вводная и все моменты в ней охватить невозможно.

Однако момент с ответственностью — он таки интересный, тут я позволю предложить альтернативную точку зрения.

Я неоднократно видел процессы — и не только в Google и Netflix — где на разработчике лежит ответственность за поддержание работоспособности своего сервиса, а SRE/ops/administrators — выполняют роль экспертов-консультантов, подавая разработчикам кирпичики (best practices, tools, processes). Но на линии огня, если что-то пойдет не так — именно разработчики, хотя, конечно, они всегда могут обратиться к экспертам за помощью.

Это, конечно, требует несколько иного подхода к найму — нанимать приходится в первую очередь взрослых и ответственных людей, с прокачанными soft skills. Но, хочу сказать как разработчик, ответственный за выкатку инфраструктуры для критических сервисов: когда ты понимаешь, что если что-то пойдет не так, и на линии огня окажешься ты лично, то ты несколько иначе подходишь что к разработке, что к code review, что к деплойменту, что к мониторингу (и это касается и твоего кода, и инфраструктуры).

Необходимости в SRE/devops — это, кстати, не отменяет — их работа по прежнему критически важна, только при этом они выходят на новый уровень — вместо решения кучи задач по отдельности проблем, они начинают решать проблемы процесса в целом, проблемы обучения людей, проблемы эргономики devops-инструментов. То есть вместо рядового бойца в строю — они становятся и командирами, ведущими за собой, и снабженцами, отвечающими за наличие у остальной команды нужного инструмента, и учителями, которые делятся своими знаниями и практиками.

Для своих сервисов — да.