Мир, труд, Май! DevOps, SRE!

Ничто не предвещало беды, когда мы (бывшие админы Инновы) в очередной раз собрались в баре. Но жизнь нас раскидала по-разному: кто-то и дальше админит, кто-то стал 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 и системный администратор.
И тут наверное будет повод задуматься и тем, и другим: мне кажется, что навряд ли они в самом деле такие плохие, но вот что испытывают сложности в общении и донесении своей мысли до остальных коллег, вероятно этот результат и говорит об этом.

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