Мир, труд, Май! DevOps, SRE!
 Публичный пост
1 мая 2020     196   

Ничто не предвещало беды, когда мы (бывшие админы Инновы) в очередной раз собрались в баре. Но жизнь нас раскидала по-разному: кто-то и дальше админит, кто-то стал DevOps-ом, кто-то SRE, а кто-то метит в CTO. И так, слово за слово, популярный сейчас вопрос DevOps vs SRE у нас перерос в философскую мысль: а кто за что должен отвечать в компании и какие обязанности скрываются за этими аббревиатурами.

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

К единому мнению за один вечер мы не смогли придти, и поэтому решили собрать мнение общественности по этому поводу. Вообще хотели сначала просто уточнить кто как понимает задачи и обязанности DevOps Engineer-а, а какие у SRE. Но коль уж всплыл вопрос вообще обсуждений, то решили собрать мнение и о других участниках и должностях.

Собственно всех, для кого эта тема актуальна, был подготовлен некоторый опросник https://forms.yandex.ru/u/5e5b9e8c645b86046d64872b/ (можно и сейчас там оставить свое мнение, только это лучше сделать до прочтения выводов, чтобы мнение было менее предвзятым)

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

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

А что видно из ответов опросника?
Во-первых, варианты DevOps инженера и SRE довольно часто соседствуют друг с другом по количеству голосов, что говорит о том, что от этих позиций в общем-то ожидают сходный функционал и обязанности: нужен человек, который не побоится и ssh-ем на сервер зайти и tcpdump там запустить, и не испытывает отвращения к коду, готов и сам что-то накодить, и на продукт компании смотрит не как на черный ящик.

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

В-третьих, и даже сейчас, когда практически все существует as-a-Service, и вроде все работает само, надо только нажать кнопку в веб-интерфейсе, еще остаются задачи, где люди хотят видеть отдельного человека: системного администратора, который решит все эти проблемы с бэкапами, ядрами линукса, и вообще всем подкапотным этого as-a-Service.

Помимо прямых выводов из подсчета числа голосов, довольно интересными, на мой взгляд, кто как видит свое участие в процессе:
В вопросах обсуждения задач с бизнесом явным лидером является позиция CTO/CIO/IT-менеджер, что логично, иначе зачем такой человек в компании?

И при этом составить компанию CTO/CIO в этом общении с бизнесом готовы меньше половины ответивших.
В вопросах же построения продукта и выбора технологий, роль CTO/CIO уже менее активная: тут меньше половины ответивших считает что CTO/CIO должен принимать участие в этом выборе, а, например, в вопросе выбора DB, победил вариант “дайте выбор специалисту (DBA), а менеджер тут не нужен”

Тут вероятно было бы хорошо посмотреть на ответы в разрезе размера компаний: где-то CTO/CIO и должен быть исключительно менеджером, а в небольших компаниях это может быть вполне играющий тренер и принимающий активное участие во всех процессах разработки и эксплуатации. Но это мне задел на следующий опросник, продумать такие варианты)

И финальными вопросами опросника хотелось узнать кто как оценивают работу себя и коллег.
Казалось бы очевидный вариант, что “самым хорошим сотрудником компании” каждый признает сам себя, оказался не верным:
Топ в ответах “кто самый хороший” и “из-за кого больше всего проблем” уверенно занимают “разработчики”, наверное как люди, которые больше всего влияют на функциональность и полезность продукта.

При этом вариант “самый хороший это я”: когда человек указывал тут должность, которую указал про себя в первом пункте опросника, выбрало меньше половины человек: суммарно хорошими себя признали только 28 человек из 65.

И так же были люди, которые признали себя в обратном утверждении, хотя уже не так много: всего 12 человек так ответили.

Второе и третье место на звание “самого плохого человека в компании” делят между собой Product owner и системный администратор.
И тут наверное будет повод задуматься и тем, и другим: мне кажется, что навряд ли они в самом деле такие плохие, но вот что испытывают сложности в общении и донесении своей мысли до остальных коллег, вероятно этот результат и говорит об этом.

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

5 комментариев 👇
Egor Biriukov, Engware Softineer 1 мая 2020

Ох.

То, что в Яндексе' назвают "девопсизацией" это, на мой взгляд, очередное русский карго-культ "а давайте Вася теперь еще и админить будет, че он сидит только и программирует, а админов уволим" и большое заблуждение.

Самое главное - DevOps это методология, а не должность.
Она предполагает тесное сотрудничество SRE и SWE команд, работу SRE над инфраструктурой(-как-кодом). Она НЕ ПРЕДПОЛАГАЕТ ситуации, когда SWE поддерживает инфраструктуру, пишет продакшен код, онколлит круглосуточно и в оставшееся время еще инкрементно улучшает процессы вокруг этого. И это неспроста.

' - классическое предупреждение: Яндекс большой, команд много, бизнес-юниты есть, у всех по-своему. Мнение автора может не совпадать и все такое.

  Развернуть 1 комментарий

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

Про Яндекс и его процессы мне, вероятно, тоже будет что сказать, но там кажется мыслей уже набирается больше чем на комментарий, вероятно на еще один пост. Скорее подожду стабилизации текущей ситуации с короновирусом: она тоже заметно повлияла на процессы происходящие в Яндексе и на мое восприятие, и тогда поделюсь своими мыслями.
Будет ли это исключительно про Яндекс, или про большие компании vs малые компании (а у меня был опыт работы в разных компаниях и коллективах), пока не решил.

  Развернуть 1 комментарий

@yatheo, очень интересно будет почитать, пиши обязательно!
У меня тоже такой пост в планах, будет интересно сравнить ощущения.

  Развернуть 1 комментарий
Stepan Rakitin, Senior Software Engineer 1 мая 2020

Ответил в опроснике. Интересно посмотреть на результат.

  Развернуть 1 комментарий

Вот дамп ответов с csv: https://fedordikarev.gitlab.io/s/zip/2020_05_01_dev_ops_devops_sre_dba_cto_chto_dlia_tebia_znachat_eti_bukvy_i_kto_za_chto_otvechaet.csv.zip
И вот этим скриптом я из него доставал какую-то доп. аналитику: https://github.com/fedordikarev/misc/blob/master/ya_forms_extra_stat.py

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб