S
Как правильно заметили выше, пока у разрабов нет безопасности в KPI или ТЗ на продукт, оно вяленько работает.
Size: a a a
2019 November 24
RR
Значит сначала менять CTO :)
RR
Или компанию
S
Плюс, имхо, у разрабов на порядок меньше внутренней ответственности, так как они не отвечают за эксплуатацию.
k
Поменять никогда не поздно😀 просто личный челлендж. Ну с ответственностью хорошая мысль, предложу наказывать рублем, если игнор рекомендаций привело к инциденту
W
а как же blameless
k
Не я один должен ходить по краю горлышка бутылки в конце то концов 😂
V
Stanislav Sharakhin
Как правильно заметили выше, пока у разрабов нет безопасности в KPI или ТЗ на продукт, оно вяленько работает.
Да. Заводить в ТЗ через Аналитиков/Технологов критерии надёжности и безопасности, например.
СТО, конечно, должен поддерживать и способствовать. Или, если ему не надо/пофиг - то зачем вы это делаете вообще?
Это как DevOps натягивать там, где ТТМ устраивает бизнес и им ок
СТО, конечно, должен поддерживать и способствовать. Или, если ему не надо/пофиг - то зачем вы это делаете вообще?
Это как DevOps натягивать там, где ТТМ устраивает бизнес и им ок
V
Это все понятно, а как строить все это когда приходишь в уже сформированные процессы. P.S. Не ради срача, а скорее совета от опытных спецов
Думаю, нужно начать с того самого DevOps. Если он уже есть / где-то внедряется как РоС, то внедряться туда. Если всех процессов нет, и DevOps нет, то... В кассу ли это вообще?)
k
devops идут на встречу, а вот разрабы не хотят. Ибо там нужно менять все, а им лень или же просто не могут
GG
Stanislav Sharakhin
Плюс, имхо, у разрабов на порядок меньше внутренней ответственности, так как они не отвечают за эксплуатацию.
Это решаемо
GG
Сам разрабатываешь - сам саппортишь. Это работает. Накосячил - разгребай
k
Ах если бы
GG
В Гугле круто сделано. Читал, что sre принимают сервис у разрабов, но если что-то идёт по одному месту - сервис возвращается на поддержку к разрабам.
GG
Ах если бы
Ну, это требует слома текущей парадигмы существования. Самое интересное, что такое sre-devops совершенно не идёт вразрез с itil/itsm
k
Хорошая идея. Но мне кажется придется менять разрабов. Жертвы курсов по коду.. однако попробовать все же стоит. Спасибо за советы
GG
Хорошая идея. Но мне кажется придется менять разрабов. Жертвы курсов по коду.. однако попробовать все же стоит. Спасибо за советы
Кого все равно придется принести в жертву
V
Хорошая идея. Но мне кажется придется менять разрабов. Жертвы курсов по коду.. однако попробовать все же стоит. Спасибо за советы
Их по-любому менять. И если они не включены уже в процессы и культуру DevOps, если они никак не отвечают за свои сервисы, то, мне кажется, это ещё неполноценный/незавершённый DevOps. И отсюда все боли и есть. Когда на предыдущем этапе недоработочка - она дальше, как раз и стреляет
V
Кого все равно придется принести в жертву
Разработчик, который devops-aware, это все же не тот же самый, и не как раньше