История один: хотели нанять робота, который питается работой, живет работой, трахает работу, а наняли человека у которого есть разные интересы (вам должно быть вообще все равно какие, даже если он стрип клубы мужские любит). Челвоек переехал в другой город и понял что город ему не подходит и решил уйти, в чем проблема? Это риск найма кандидата из другого города.

Истори два: вместо того что б нанять нужного кандидата за меньшие деньги (вы ж сами сказали что увеличили зарплату в два раза) и дать ему больше отпуска, пусть в устном договоре или отгулами вы его профукали. Молодцы ребята. Зато не прогнулись!

История три: ну бывает. Вы ж сами заметили что даже ваши кандидаты не всегда читают контракты которые подписывают. Обращайте на это внимание при подписании контракта, уточняйте 100500 раз. Если для вас это критично, то подходите к этому вопросу ответственно. Конечно можно полагаться на кандидатов, но вопрос больше к вам.

История четыре: ну. Единственная история в которой кандидат поступил нехорошо.

История пять: тоже что и три

История шесть: ну не согласился и что? Он же не подписал офер! Может ему больше денег предложили или повышение на текущем месте или приняли на работу в компанию которая как он думал выше его уровня.

История семь: ну плохо проработали мотивацию. Надо было оговорить четко дать понять кандидату что вы ищете человека на длительное сотрудничество на конкретное место

История восемь: ну не понравились вы человеку. Или он понял что не тянет. Обязательно надо было завершать ритуал собеседования? Скажите ему спасибо что сэкономил ваше время.

Единственный вывод по данной статье — неадекватный рекрутинг. То есть вы ж подобными статьями сами уменьшаете процент людей которые к вам пойдут, потому что появляется шанс что 1 из 100 кандидатов подумает что-то вроде «идти к ребятам или нет? Они ж потом могут начать на доу расказывать про меня истории». В любом случае спасибо за статью. Когда я начинаю думать что мне платят слишком много денег, я читаю что-то подобное и понимаю за что.

Лол. Учитывая что девопс это набор практик главные цели которых:
а) уменьшить TTM
б) решить проблему отсутствия единого приоритета между командами

То перевод режима деплоя в математическое пространство (главная идея SRE) очень неплохо ложится на идеологию DevOps.

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

Я думал что это подмножество DevOps.

экспертное мнение в технологиях и должны знать от 0 до 255, а так же другие подводные камни своих зверюшек.

Вообще больше похоже на позицию архитектора.

но могу сказать, что команды DevOps-ов нужны только продукту, который проходит апгрейд

Собственно в первой части статьи я говорю о том что DevOps нужен компании, которой надо уменьшить time-to-market и собственно на уменьшение ttm и повышение эффективности кросскуммуникаций между командами и направлен DevOps как методология

В иных случаях, как по мне, лучше максимально далеко продумывать архитектуру вашего продукта с нуля

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

Хм. Ну я работал и консультировал такие компании как grammarly, datarobot, ring.com, в принципе это достаточно большие и успешные компании.

Senior DevOps-ы — это уже типа, админы зоопарков

Хм. Я вот вообще считаю, что такой позиции как DevOps не должно существовать, если это не подразумевает позицию евангелиста.

так это ж в рамках команды.

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

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

А вот на тему размазывания ответственности интересно. Что вы имеете ввиду? Что разделение ответственности между командами это хорошо? Так это ведь как раз из-за чего девопс и появился, из-за того что разные отделы отвечали за разное...

1) Так дев > опс это историческое понимание и я дальше в статье прихожу к тому что не больше.
>Самое смешное, что почти всё из списка выше не вопрос стоимости, как обычно считают, а вопрос экспертизы: когда люди, которые умеют что-то делать, помогают другим людям, которые не умеют этого делать. Таким образом, редко получается нанять дешёвого человека, который будет опытным и при этом не против поделать какую-то рутинную фигню.

Аналогично и по остальным пунктам. У меня такое ощущение что все читают вступительную «историческую» часть, тригерятся и не дочитывают до конца.

DevOps это набор практик направленных на уменьшение TTM посредством единого управления приоритетами у ops и dev команд. В данном случае я скорее веду к NoOps как подмножеству девопс и мне это кажется наиболее рабочей схемой.

Эм. Я не понимаю к чему вы ведёте. Опс команда характеризуется тем что делает общую работу в том числе и поддержку. Я в статье предлагаю чтобы отдельной команды, которая поддерживает\релизит и так далее не было, но была команда которая занимается внутренними продуктами (внутренние SaaS/PaaS) и шарит экспертизу. Плюсы этого тоже описаны, в частности возможность делать продукт\консультацию, то есть сменить flow с поддержки на продуктовый с всеми сопутствующими выгодами. Почему вы эту команду называете devops? И с чем конкретно вы спорите?

о боже, я уже третий комментарий пытаюсь понять где я говорю о выделенной команде, которая занимается devops. Можете цитату, пожалуйста? Очень вас прошу!

не очень понял к чему это :)

Девопс команда, по хорошему, может быть только командой евангелистов девопс, в то время как в современном IT принято девопс командой называть всех от релиз инженеров до просто опсов.

ммм.. если честно я не нашел ни одного упоминания девопс команды в статье.

хм. А где я называю команду platform инженеров командой девопс?

так я вроде как раз в статье и обозначил разницу между командой platform инженеров и опсов. Хм.

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

эм. Так и у меня про этом же.