у вас SRE за SMART атрибутами накопителей на железе в стойках в ДЦ следят круглосуточно? за здоровьем рейд массивов?

У нас есть и свои датацентры так что да) но не будем о грустном

а мониторинг с алертами накой?

Который работает. Выше называли де-факто стандарт сегодня

грустно чот

в своё время, когда я ещё верил в эти ваши аджайлы, меня тоже интересовал вопрос, как монтируются скрамовые спринты с пожарами на лайве, которой той же команде тушить иногда надо

и я его задал уважаемому сенсею со scrum.org, на семинаре которого я присутствовал, и который в аджайле шарит наверное, думал я

и сенсей мне ответил - отдельная канбан доска + резервирование ресурсов (20-30 процентов) на непредвиденные расходы

Ну обычное бакетное планирование, а чё думал скрам это ответ на все вопросы?

Вообще есть клёвый видос от alan holub на тему war is peace, slavery is freedom, scrum is agile

Лол. Так уж получилось, что на эту тему у меня тоже история из текущей компании.

Где-то месяца 3 назад мы столкнулись с абсолютно новой для себя проблемой: у разрабов кончились задачи. При этом нельзя было сказать, что с продуктом всё отлично, и у техподдержки была куча работы.

Я обратил внимание на то, что у нас стало существенно меньше отложенных задач от разработчиков. Типа "вот тут нужно поэкспериментировать с такой-то ещё библиотекой" и так далее. Ну, в общем, составил дерево текущей реальности, и нашёл корневую причину. Их две оказалось. Но они связаны, так что можно в одну объединить: разработка не получает обратную связь от эксплуатации.

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

С третьим пунктом сначала тяжко было. Почему-то они не считали что это норм)
Мы даже сделали на время так, что по каждому инциденту в эксплуатации эксплуатация обязана ставить таски разработчикам.

Ну и конечно активнее всего этим пользовались дежурные разрабы)
Они лучше понимают где и что можно поменять.

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

Девопс это налаживание обратной связи от эксплуатации к разработке. Конечно, если это одни и те же люди, то у тебя самый короткий цикл обратной связи из возможных. Но не всегда это могут быть одни и те же люди)

просто кмк витуху между стойками точно не SRE должен тянуть

Ну там есть нетопсы)

У нас как - челики которые витуху тянут и датацентры прочее нетопсы, челы которые тераформы куберы - девопсы. Челы которые капасити менеджмент и прочие циферки и что б не падали пинать разработчиков - sre

девопс это не человек а команда, в ней есть дев капабилити и опс капабилити в разных людях

Я в курсе, в сожалению термин devops извращен до опс который умеет в автоматизацию

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

Это хэштэг, до методологии там как бы далеко

Да, так точнее

Я всё жду когда будут нанимать gitsecops

и я не оч понимаю что значит "большие проекты"
devops team должна быть такого размера чтобы угостить одной пиццей
она держит один или несколько сервисов - от кода в гите, через пайплайны в лайв, и она понимает что там в лайве происходит
любой большой проект делится на несколько feature teams и что-то типа platform team которая решает общие вопросы

Вот platform team норм понятие.

а когда кубернетес кластер разваливается, потому что рейд массив на кубернетес мастере развалился, т.к. за железом никто не следил, что делает devops team ?  пиццу ест ?