Инновации и инсайты в мире Java из первых уст. Новая конференция Java Fest — 21 марта >>
×Закрыть
devops консультант
  • DevOps простыми словами: как IT-команде делать важное и зарабатывать больше

    Хорошая статья. Но.

    >Структура должна быть как можно более плоской, никаких начальников. Операционистов не должна волновать политика. Они не должны думать о том, «кто попросил это сделать», и оценивать задачи, основываясь на иерархии. Законно то, что логично. «Более прав» тот, кто лучше обосновывает.

    Политика начинается тогда, когда нет структуры. Если нет человека который решает, тогда побеждает тот кто громче кричит. То что у вас крик измеряется логикой — ничего не решает. Рассуждайте так — есть заказчик, а есть исполнитель. Если к вашим исполнителям приходят два заказчика, то как исполнитель должен решить чью работу делать? Почему это должен решать исполнитель? Каким образом инженер может знать всё о том что надо продукту в конкретный момент и что важнее для продукта конкретно сейчас?
    В маленьких бизнесах справедливо требовать от инженера знания продукта, но на самом деле это менее эффективно чем иметь продукт менеджера, который знает что надо продукту и который (которая, которые) является принимающим решение.

    Иначе начинается самотрактовка нужд компании, блат, выбирание интересных задач вместо нужных. Может даже дойти до синдрома вахтера, когда какой-то человек будет считать что стабильность, например, важнее фичи. Или наоборот, что фича важнее стабильности.

    >Люди должны быть самостоятельными. Соотношение goal driven против process oriented среди сотрудников должно быть максимально в пользу первых, но для баланса нужны и вторые.

    Если вы выбраковывете людей тоннами, то goal driven ок. Задачи заканчиваются, надо оттачивать и улучшать. Я, как представитель goal driven людей отлично понимаю что я слаб в шлифовании и улучшении и поэтому часто нанимаю себе в команду именно process oriented person. Иначе всё быстро запилим, а потом все сидят выгорают над имплементацией и полировкой.

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

    Это очень опасно. Видел человека, который запилил модули для терраформа, которые были просто врапперами над одиночными ресурсами к терраформу. Типа модуль с кучей переменных а внутри только один ресурс в котором подставлены переменные.

    >Продукт использует пользователь. И он должен быть доволен. У нас не в ходу фраза «ну пускай кто делал, тот и разбёрется». Наш operantions — «затычка» в любой боли, которой ещё не найден конкретный хозяин.

    Справедливо. Но если нет овнера, то как понять какая «боль» приоритетнее?

    >всё должно отвечать на вопрос, «как создать ещё сто таких, чтобы было одинаковое и удобное»
    противоречит нелюбви к автоматизации. Опять же, надо ли всегда думать о том как создать «сто таких» или иногда достаточно иметь какие-то супер уникальные штуки?

    >По возможности, отсутствие неинтерактивных коммуникаций (вроде имейлов).

    Имейлы важная часть общения, когда нужен не срочный, но обстоятельный ответ.

    >По возможности, присутствие тикетной системы.

    интересно, а когда тикетная система не нужна?

    В общем статья хорошая и имплементация интересная, особенно если работает, но если честно иногда складывалось ощущение что вы забыли что единственный ключевой слоган девопс это единство приоритетов. Если у вас есть человек который разруливает приоритеты для ops и dev команды и сразу все команды отвечают за стабильность и за time to market, то это девопс. Если у вас такого человека нет, то девопс тоже может быть, но только до тех пор пока у всех в головах есть одинаковое понимание соотношения time-to-market и стабильности. Хотя, если честно, я наблюдал только случаи, когда начиная с двух человек одинакового понимания уже не было, была иллюзия одинакового понимания, которую было очень легко разбить.

  • Разыгрываю билет на DevOps Days

    В общем, победитель выбран — Nikolay Ovsiannikov. Поздравляшки, обнимашки.

    Поддержал: MythBuster
  • Почему я иду на You Gotta Love Frontend

    Коменты жесть просто. Ребята хотят сделать большую конфу серьезного уровня, это сложно и такое надо только поддерживать!

  • Яким кандидатом не треба бути: 8 реальних історій

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

  • Яким кандидатом не треба бути: 8 реальних історій

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

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

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

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

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

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

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

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

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

  • Говорим о DevOps: ответственность и задачи

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

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

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

  • Говорим о DevOps: ответственность и задачи

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

  • Говорим о DevOps: ответственность и задачи

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

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

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

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

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

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

  • Говорим о DevOps: ответственность и задачи

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

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

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

  • Говорим о DevOps: ответственность и задачи

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

    Поддержал: Hanna Mazurkevych
  • Говорим о DevOps: ответственность и задачи

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

    Поддержал: Oleg Mykolaichenko
  • Говорим о DevOps: ответственность и задачи

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

    Поддержал: Oleg Mykolaichenko
  • Говорим о DevOps: ответственность и задачи

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

    Поддержал: Oleg Mykolaichenko
  • Говорим о DevOps: ответственность и задачи

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

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

  • Говорим о DevOps: ответственность и задачи

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

  • Говорим о DevOps: ответственность и задачи

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

  • Говорим о DevOps: ответственность и задачи

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

  • Говорим о DevOps: ответственность и задачи

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

    Поддержал: Oleg Mykolaichenko
  • Говорим о DevOps: ответственность и задачи

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

  • Говорим о DevOps: ответственность и задачи

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

← Сtrl 123 Ctrl →