130 человек в канале в день запуска и 9 на первой встрече. Через пять месяцев — 220 в канале и от 15 до 42 на встречах. Это хорошо или плохо? Контент и тема тут почти ничего не решают.

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

Дальше — один кейс: запуск внутреннего SRE-сообщества в продуктовой компании на несколько тысяч человек, пять месяцев, шесть встреч, статистика посещаемости и оценок. Компанию не называю, внутренние названия обезличены. Цифры настоящие.

Формулировка проблемы почти всегда одинаковая. SRE-практики фрагментированы по командам, уровень зрелости разный, и почти никто не знает, что происходит у соседей. Отдельно — то, что я считаю главной проблемой SRE вообще: надёжность не входит в привычку. Когда сжимается time to market, регулярные вещи отваливаются первыми. Нет бэкапов, не обновляются компоненты, не проводится нагрузочное тестирование, никто не планирует capacity. Каждая команда наступает на эти грабли самостоятельно и в своём темпе.

Сообщество должно стать местом, где этот опыт не пропадает.

И вот деталь, которая потом всё и определила. Комьюнити было одним из пунктов в списке задач процессной роли вокруг качества и надёжности, а не целью само по себе. Incident and problem management работает с качеством, качество упирается в надёжность, надёжность требует общих практик и стандартов — вот тут и заводится сообщество. То есть инструмент. У инструмента нет своего бюджета и своего времени, и это первая развилка. Большинство внутренних сообществ проходят её не глядя.

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

Старт это упрощает. И задаёт ловушку: когда на руках готовый чек-лист из пяти пунктов, хочется закрыть его целиком и сразу. Что я и сделал.

Начал я с людей. Двое коллег накидали список тех, с кем стоит познакомиться, я завёл доску и пошёл по списку разговаривать. Из этих разговоров собралось ядро — шесть человек из разных команд, включая меня. Дальше цель, правила, канал, рассылка, пространство в базе знаний. В конце сентября зафиксировали правила комьюнити, в самом начале октября провели стартовую встречу.

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

Шесть встреч за пять месяцев выглядят так.

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

Параллельно ядро собиралось раз в неделю на полтора часа. Это самая недооценённая часть: публичная жизнь комьюнити — шесть встреч, внутренняя — двадцать созвонов ядра, где решалось всё остальное. На них родились техрадар по практикам надёжности, идея факап-митапов без записи, ежемесячный дайджест состояния надёжности и роль reliability champion — человека в команде, который отвечает за надёжность, по образцу security champions.

Из таблицы я вытаскиваю три вещи, и каждая ломает общее место про сообщества.

Первое: посещаемость не растёт, она пилит. 9, 32, 15, 42, 35, 24. Никакой кривой роста, которую можно показать руководству, здесь нет и не появится: каждая встреча собирает свою аудиторию по теме, а не «аудиторию комьюнити».

Второе: посещаемость и польза не связаны. Самая многолюдная встреча — провокационная, про то, почему бюджет надёжности устроен не так, как в известной книге: 42 человека и оценка 4,52. Самая высокая оценка, 4,85 по всем трём шкалам, у встречи про малоизвестные возможности внутреннего DNS-сервиса, куда пришло 24 человека, почти вдвое меньше. Провокационная тема собирает людей, узкая техническая приносит пользу тем, кто пришёл. Если оптимизировать сообщество по посещаемости, вторые встречи исчезнут первыми.

Третье: первые три строки в таблице пустые. Обратную связь начали собирать с четвёртой встречи, через три месяца после старта. Это и есть главный провал. Лень тут ни при чём.

Дальше половина текста будет про инструменты, поэтому сразу — откуда они и что из них сработало.

Community Canvas (community-canvas.org) — девять блоков: цель, идентичность, ценности, определение успеха, опыт, роли, правила, управление, коммуникация. Мы прогнали через него сообщество целиком. Ценность канваса не в том, что он даёт ответы, а в том, что показывает, где ответа нет: блоки «цель», «ценности» и «правила» заполнились за один вечер, а «определение успеха» и «управление» остались с формулировками вида «снижение MTTR на XX%». Вот этот XX и был диагнозом на весь следующий год. Я прочитал его как «допишем потом».

Community Technology Framework от The Community Roundtable (communityroundtable.com) — про технологический слой сообщества. Он заставляет развести три вещи, которые обычно свалены в кучу: инструмент общения, инструмент управления и инструмент учёта. У нас всё это жило в одном корпоративном мессенджере, и именно поэтому потом не удалось вытащить оттуда метрики.

Модели управления — раздел Governance в методичке Еврокомиссии по сообществам практиков: кто принимает решения, кто спонсирует и как сообщество взаимодействует с материнской организацией.

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

Про «чего не делает» стоит сказать подробнее. Различать «зачем мы существуем» и «что мы конкретно делаем» кажется занудством — ровно до вопроса «а вы можете отвечать за аптайм?». Первое отвечает, зачем сообщество вообще завели, и почти не меняется со временем. Второе — список дел с чёткими границами. Сообщество не может отвечать за то, чем не управляет: заставить команду оно не вправе. Поэтому «все команды внедрят стандарты» — плохая цель, а «у всех команд есть доступ к стандартам, обучению и поддержке» — рабочая. В уставе под это заводится отдельный список «чего мы не делаем»: не принуждаем к стандартам, не владеем чужими сервисами, не делаем за команду вместо того, чтобы научить, не гарантируем конкретные цифры надёжности. Список защищает не столько компанию от сообщества, сколько сообщество от того, что на него навесят лишнего.

Трёхуровневая модель измерения. Её я взял из change management: Prosci меряет изменения на уровне организации, отдельных людей и самой работы по изменениям. Третий уровень я заменил на само сообщество. Мерить надо на всех трёх сразу, и смешивать их нельзя. Уровень организации — инциденты, MTTR (время восстановления после сбоя), потребление бюджета ошибок, DORA-метрики; обязательно в сравнении с контрольной группой команд, которые с тобой не работали. Уровень поведения людей — как быстро подхватывают практику, насколько глубоко её используют, правильно ли применяют, как часто приходят за советом. Уровень самого сообщества — охват, engagement rate, доля прошедших обучение, скорость появления контента, довольны ли стейкхолдеры.

Опережающие и запаздывающие индикаторы. Запаздывающие показывают, что уже случилось: сколько команд внедрило, как изменилась частота инцидентов. Для отчётности годятся, для управления нет: когда ты видишь «внедрили трое из ста», корректировать подход для остальных девяноста семи уже поздно. Опережающие предсказывают: активность в канале, число команд, назначивших своего reliability champion, готовность участвовать в пилотах, оценка после обучения вместо самого факта обучения. Что следить за показателями по ходу вообще окупается, видно в опросе McKinsey 2017 года: там, где KPI отслеживали во время внедрения, об успехе сообщил 51% респондентов, где не отслеживали, только 13%. Это самооценка, а не замер, но разница почти вчетверо.

Метрики самого сообщества. Engagement rate, talk rate, love rate по чату, CSAT после событий, eNPS раз в квартал. Плюс качественные, которые почти никто не считает, а зря: какую долю ответов дают сами участники, а не модераторы, время до первого ответа на вопрос и доля вопросов, получивших решение. Последние две FeverBee прямо предлагает для бенчмаркинга сообществ. Правило внедрения простое: выбрать три-пять метрик, а не все сразу, и снять базовый уровень до старта.

Всё это у нас было написано. Дальше — почему написанное и работающее оказались разными множествами.

130 человек в канале и 9 на первой встрече. Это семь процентов, и это был день запуска — момент максимального внимания, когда про сообщество написали везде, где могли. Через пять месяцев в канале было около 220 человек, а на встречи стабильно приходило от 15 до 42. Разрыв между «подписан» и «участвует» я поначалу читал как свой провал. Перестал, когда попал на встречу лидов внутренних сообществ и услышал цифры соседей: у сообщества security champions канал в разы больше, а доля пришедших на мероприятия примерно та же. Низкая посещаемость, отсутствие интереса к опросам, трудности с поиском спикеров и тем, текучка активистов — общий список болей всех лидов, а не чей-то личный.

Правила пишутся как регламент, а рычагов под ними нет. В нашем документе с правилами — еженедельные короткие доклады, обязательные SLI/SLO минимум по трём метрикам на сервис, квартальный аудит соблюдения стандартов, публикация постмортемов в течение пяти рабочих дней. По факту встречи шли раз в месяц. Аудита не было ни одного. Мы описали центр компетенций с полномочиями, которых у сообщества не было. Легитимизация, то есть превращение кружка по интересам в игрока с мандатом, в наших же заметках того периода формулировалась осторожно: «возможно, но не сразу и не быстро».

Обратная связь появляется поздно, а системные метрики — никогда. Первые три встречи прошли без единого замера: ни оценки, ни интереса, ни пользы. Опрос после встречи мы запустили только в конце января, и он сразу заработал: 4,52, потом 4,18, потом 4,85. Инструмент был дешёвый, рабочий и доступный с первого дня. Мы просто три месяца до него не доходили. При этом опросник вовлечённости на два десятка вопросов был написан, engagement rate, talk rate, love rate и eNPS расписаны с формулами и частотой сбора — и ни один из них не был снят ни разу, включая базовый уровень. Причины мы записали честно: люди пассивно относятся к опросам, а вытащить активность из корпоративного мессенджера технически неудобно. Обе были известны заранее, и обеих хватило.

Отдельный симптом: в итоговой таблице метрик у строки «размер комьюнити» базовый уровень стоял 200 человек, а цель на конец года — 50+. Это не опечатка, это две разные сущности в одной строке: подписчики канала и живые участники. Мы сами в своём документе не смогли назвать, что считаем размером сообщества.

Роли расписаны, людей под ними нет. В структуре — ядро, модераторы, контент-мейкеры, менторы, инициаторы, активные участники, наблюдатели. Напротив менторов в документе стоит прямая запись: «Сейчас их нет». Наставничество было главным, что мы обещали новичкам. И единственной ролью, которая так и не наполнилась.

Никто не считает участие в комьюнити работой. Это главный пункт, и он объясняет все предыдущие, включая три пустые строки в таблице.

В требованиях к запуску мы честно написали, что нужно: мандат от руководства, признание вклада в performance review, время участников — от 4 до 8 часов в месяц для обычного участника и от 12 до 24 для ядра, бюджет на офлайн, возможность учиться в рабочее время. Написали и пошли делать встречи, потому что встречи делать понятно, а разговор про мандат нет.

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

Отсюда механика, которую я осознал слишком поздно. Пока участие не имеет веса в оценке сотрудника, комьюнити конкурирует за время с тем, что вес имеет. В такой конкуренции оно всегда проигрывает, и остаётся ровно то, что времени не требует: подписка на канал. 130 подписчиков и 9 человек на встрече — это не провал вовлечения, это точный отчёт о том, сколько людей нашли способ оплатить участие из своего кармана.

Сюда же три пустые строки в таблице. Разослать опрос, собрать ответы, посчитать, принести на созвон ядра — это час работы на встречу. Час, которого не было ни у кого, потому что он не был ничьей задачей. Метрики сообщества не появляются от того, что кто-то написал хороший опросник; они появляются, когда у человека есть оплаченное время их собирать.

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

Как выглядит сообщество, у которого этот вопрос решён, публично разбирает Евгений Харченко в докладе «DevOps Community: от идеи до движения» на DevOpsConf 2026 — весь путь от инициативы до движения, включая ту самую штатную роль community lead. Дело не в наборе форматов и не в метриках. Дело в том, что у сообщества есть человек, для которого оно работа, а не общественная нагрузка поверх основной. Там, где такой человек есть, метрики появляются сами: их есть кому собирать и есть перед кем защищать.

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

Это та же история, что с SRE-практиками вообще. Если бизнес не готов платить за надёжность скоростью, ресурсами и фокусом, бюджет ошибок и ограничения релизов он воспринимает как тормоз, и практики отбрасываются как мешающие. С сообществом идентично: если компания не готова платить за обмен знаниями рабочим временем и строчкой в оценке, сообщество остаётся хобби, а хобби в корпоративной среде живёт до первого горящего квартала. Готова ли компания платить, выясняется только в разговоре с бизнесом. Я этот разговор отложил и теперь знаю, что их нужно четыре.

Провести их надо именно в таком порядке. Ни один не про «дайте нам чат».

Разговор первый: запуск. Здесь нужен ответ на «зачем мы существуем», а не перечень мероприятий. Плохая формулировка на старте — «сто процентов команд внедрят единые стандарты надёжности». Это отчётная галочка. Она про соблюдение правил, игнорирует разницу между командами и делает сообщество провалившимся ровно в тот момент, когда девяносто седьмая команда не внедрила. Рабочая формулировка про вклад: ускорить принятие практик, помогая командам получать измеримое улучшение надёжности без потери скорости разработки. Дальше под неё три-четыре измеримых цели на год, список дел и список того, чего вы не делаете. Всё это укладывается в одну страницу устава, и эта страница — предмет разговора со спонсором, а не внутренний документ ядра.

Разговор второй: права. Мандат — не про «разрешите нам собираться». Это ответы на конкретные вопросы: где сообщество закреплено формально, кто спонсор из руководства, на какие решения его голос влияет и в каком виде (участие в архитектурных ревью, RFC-процесс, комитет по стандартам), какие практики за ним закреплены — SLI/SLO, политика бюджета ошибок, шаблоны постмортемов, инструкции на случай инцидента. И симметрично — что сообщество не делает, чтобы через полгода на него не повесили дежурство по чужим сервисам. Полезно понимать, какую модель вы вообще строите. Сообщество практиков, где участие добровольное, а влияние держится на авторитете, — это одно. Платформенная команда с продуктом и обязательствами — другое, и метрики у неё другие. Без этих ответов мандата нет. Есть доброжелательность, а это другое.

Разговор третий: деятельность участников. Тут два вопроса, и оба неудобные. Сколько часов в месяц компания согласна считать рабочим временем — отдельно для участника, отдельно для ядра. И где участие отражается в оценке человека: в целях, в перформанс-ревью, в карьерном треке, в рекомендации на повышение. Если ответ на второй вопрос «нигде», первый теряет смысл, а сообщество можно смело планировать как чат по интересам с редкими всплесками активности. Максимальная версия — оплачиваемая роль community lead, минимальная — строчка в целях лида и явное «да» его руководителя. Между ними промежуточные варианты: признание вклада на общих встречах, включение активности в описание грейда, квота времени в спринте.

Разговор четвёртый: активность внутри. Это отчётность, и вести её надо на языке вклада, а не заслуг. Когда меряешь заслугу, вопрос звучит так: «сколько процентов команд внедрили стандарты благодаря нам?» Честного ответа на него нет, на надёжность влияет всё сразу. Когда меряешь вклад, вопрос другой: «что изменилось у команд, которые с нами работали?» Отсюда форма отчёта: не «внедрили трое из ста», а «пять пилотных команд улучшили стабильность при нашей поддержке, три из них значимо, остальные девяносто пять пока вне охвата». Те же данные, но первая формулировка закрывает сообщество, а вторая объясняет, куда давать ресурс.

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

Отдельно про то, как показывать посещаемость. Шесть встреч в виде графика выглядят как пила, и любой руководитель спросит, почему нет роста. Правильный ответ: роста и не должно быть. Каждая встреча собирает аудиторию темы, а не аудиторию сообщества, и сравнивать надо не встречу с встречей, а оценку пользы с затраченным временем участников. 24 человека, поставившие 4,85, — это лучший результат в таблице, хотя по посещаемости встреча предпоследняя.

Чужой опыт раньше собственного плана. Ещё до старта я договорился о звонке с человеком, который несколько лет вёл внутреннее DevOps-сообщество. Час разговора дал больше, чем месяц чтения: Community Canvas как рабочий инструмент, конкретные метрики чата, форматы (короткие митапы на 20–30 минут, отдельный формат хардкорных сессий с терминалом, награды активным участникам раз в полгода), внутренние инструменты как inner source, то есть внутренний опенсорс. И две фразы, которые я потом повторял чаще всего: сопротивление лечится критической массой, а не борьбой с сопротивлением; community lead — это должность.

Опрос после встречи. Три оценки — общая, интерес, польза — и всё. Дёшево, заполняется за десять секунд, даёт разговор с ядром на языке цифр вместо «вроде норм зашло». Единственная претензия к этому решению — что оно случилось на четвёртой встрече, а не на первой.

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

Reliability champion вместо полномочий. Прямая калька с security champions, которые в компании уже работали. Логика: сообщество без полномочий не может обязать команду, но может дать команде своего человека, у которого есть роль и повод. Заодно это опережающий индикатор: число команд, назначивших его у себя, предсказывает будущее принятие практик лучше, чем любой отчёт о внедрении.

Отказ закрывать чек-лист. К пятому месяцу стало понятно, что документы написаны на год вперёд, а живёт из них одна встреча в месяц. Дальше имело смысл не дописывать стратегию, а закрывать разрыв между двумя сотнями в канале и десятком активных.

Канал — это не сообщество, и метрика подписчиков врёт на порядок. Считать надо пришедших и активных авторов в месяц, и снимать это с первой недели. Если базовый уровень не снят на старте, он не будет снят никогда: через полгода уже нечего сравнивать, и любая цифра роста становится неопровержимой и бессмысленной одновременно.

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

Легитимизация делается до правил, а не после. Мы написали правила центра компетенций и надеялись дорасти до полномочий, описанных в них. Работает обратный порядок: сначала мандат и признанное время участников, потом регламент под этот мандат. Иначе получается документ, который никто не нарушает только потому, что никто его не исполняет.

Незавершённая работа привлекает участников, законченная — только пользователей. У Питера Хинтьенса (Pieter Hintjens) в «Социальной архитектуре» это сказано про открытый код, но во внутреннем сообществе работает так же. Стратегия на год, вычитанная и красивая, не оставляет дыр, в которые можно влезть. К моменту, когда мы выкатили полный набор документов, встроиться в него было некуда — оставалось только читать.
Первая волна — энтузиасты, и они не остаются. Та же книга: аудитория приходит волнами, и энтузиасты, пришедшие на старте, участниками обычно не становятся, зато разносят весть дальше. Мы считали отток первой волны провалом, а это её нормальное поведение.

Один лидер — это не команда лидеров. Во внутреннем регламенте компании первым пунктом стояло «команда лидеров, и ключевое тут именно команда, потому что на плечах одинокого лидера всё довольно быстро загнётся». Я прочитал этот пункт, согласился, собрал ядро из шести человек — и всё равно остался единственной точкой сборки. Ядро отвечало за темы и доклады, а связь с менеджментом, стратегия, еженедельный созвон и внешние коммуникации висели на одном человеке. У Хинтьенса про выгорание волонтёра сказано прямо: главный фактор риска — концентрация ответственности на одном человеке, срок — от полутора до трёх лет. Я не дошёл до выгорания, я просто сменил работу через пять месяцев после старта. Для сообщества это тот же сценарий.

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

Внутреннее сообщество запускается легко и умирает тихо. Легко — потому что чек-лист закрывается за месяц: канал, цель, ядро, регулярность, артефакты. Тихо — потому что ни один из этих пунктов не отвечает за то, ради чего всё затевалось.

Инструменты, которые я перечислил, работают. Community Canvas показывает дыры, устав не даёт навесить на сообщество лишнее, три уровня измерения и опережающие индикаторы дают честный разговор с бизнесом вместо «нас двести человек». Но все они работают поверх одного условия: компания признала, что участие в сообществе — это работа, а не хобби. Если условие не выполнено, канвас превращается в красивый документ, метрики — в строчки «уточним позже», а сообщество — в ещё один чат, где двести человек молча читают анонсы, и на встречу приходит девять.

Порядок, который я бы взял в следующий раз, такой. Сначала разговор про мандат и часы. Не прозвучало ничего конкретного — не запускайся. Потом три оценки после первой же встречи. Потом второй человек, который может провести встречу вместо тебя. И только потом стратегия — если она к этому моменту ещё будет нужна.

Михаил Савин — руководитель отдела SRE в h3llo.cloud. До этого был старшим аналитиком SRE в Авито и техлидом SRE направления AppSec в Positive Technologies.

Член программного комитета DevOpsConf. Веду Telegram-канал и блог «Мишка на сервере» про SRE и DevOps.

Связаться: @jtprogru