Действительно, отдельные SRE нужны не во всех организациях, а начиная с некоторого размера инфраструктуры.
«SRE — админ, а ни разу не программист» — это распространённое заблуждение. Если это действительно так в какой-то организации, то эти SRE работают неправильно.
В гугле тоже есть SET (Software Engineer in Testing). Это не тестировщики, которые пишут тесты (боже упаси тестируют руками), а программисты, которые пишут, например фреймворки для тестирования. Тесты пишут сами продуктовые программисты.

Классификация фич на бизнес и инфраструктурные — во-первых не взаимоисключающая, а во-вторых не всепокрывающая. Продукт может быть внешним, для конечного пользователя, или может быть внутренним — инфраструктурой. SRE, как и продуктовые (бизнес? SWE, в терминологии гугла) разработчики работают над общей целью: хороший, надёжный, предсказуемый продукт для пользователя. Технически и SWE и SRE пишут дизайн доки, код, следуют практикам софтверной инженерии. только у них разный фокус и, соответственно, разные сферы экспертизы. SWE могут лучше знать предметную область (мед. сферу, нефтяную, итд), а SRE часто намного глубже знакомы с идеями и приёмам построения распределённых систем, управления надёжностью, рисками, практических аспектов эксплуатации абстрактной системы «в продакшне», что также подразумевает знание сетей, протоколов, внутренностей ОС.

К вопросу выше, если под бизнес-фичами подразумевать рюшечки, разделы на сайте, кнопки в пользовательском интерфейсе, новые пользовательские сценарии, то ответ скорее нет: для этого есть SWE разработчики, у которых больше контекста, и которые это сделают более эффективно (т.е. SRE может стать таким же эффективным, но потребуется сначала ознакомиться с предметной областью, фреймворками итд).

Разработать системы контроля надежности, например, балансировки нагрузки, ответа на непредвиденные ситуации, мониторинг, резервное копирование и особенно восстановление, планирование роста, консультации SWE на этапе проектирования о последствиях их изменений для инфраструктуры — задачи, с которыми в основном работают SRE. Многие SWE смогли бы также решать эти задачи, после некоторого ознакомления с предметной областью, фреймворками итд.

SRE — это одна из реализаций идей DevOps, которую предпочел гугл. В частности, основное отличие SRE от традиционного DevOps, что SRE инженеры — это не Ops, а software инженеры, которые подходят к решению devops задач как к Software Engineering задачам.

Есть

А як у OurSQL з CAP теоремою?

Чтобы быть нерезидентом не обязательно оформлять ПМЖ. Можно «временно проживать» вне территории Украины, становясь или не становясь на консульский учёт другой страны. Такое может длиться годами?

Уличные музыканты/артисты: en.wikipedia.org/wiki/Street_performance

Про баскеров, видимо

нет, с каменюками и швабрами — это кёрлинг. А тут — хёрлинг: с клюшками и на траве ru.wikipedia.org/wiki/Хёрлинг

В некоторых компаниях практикуются «жетоны/талоны на алкоголь». Например, 3 порции на вечер. Остальное, например, — платно.
Кроме того, это не заменяет Code of Conduct, с которым все ознакомлены и который обязателен к выполнению.

Не знаю, что конкретно есть ретроспектива (звучит как-будто баззворд из психологии/социологии), но многие крупные IT компании давно культивируют у себя культуру blameless post-mortem, например www.businessinsider.com/...meless-post-mortem-2012-5 Это позволяет намного более конструктивно исследовать случившиеся проблемы и делать выводы.

Зверніть увагу, що для розміщення коштів на рахунку за кордоном формально необхідно отримувати персональну ліцензію НБУ (напр. delo.ua/...ovskih-schetov-z-215901/

А как насчёт женщин-программистов, которые не попадают под призыв?

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

Один из возможных вопросов, которые возникнут к Вам: гражданину Украины, чтобы открыть счёт в иностранном банке нужна лицензия НБУ (индивидуальная, выдаётся на год, zakon4.rada.gov.ua/...s/show/z1413-04 ). Иначе — штрафы.

В контексте комментария выше (dou.ua/...ic/9914/#477256 ), что вы подразумеваете под «кластером Oracle»?

Отличная работа!
Я думаю, что проделанную работу можно ещё усовершенствовать:
* Сделать развёрнутое описание (вроде того, что тут в посте) в README корня репозитория прямо на github. Если после этого тут просто оставить ссылку, то информации будет примерно столько же, но захват аудитории в разы больше.
* Добавить описание API, если вы считаете, что кому-то может быть полезно использование кода как библиотеки.
Я с Java особо не работаю, потому не в курсе, как там принято описывать API библиотек, но наверно какой-то javadoc c примерами использования стал бы решающим при завоевании ещё десятка-другого сердец пользователей.