В конце прошлой недели, 24-25.11 прошел Highload, а сразу за ним 26.11 DevRel'ы, многие из которых работали на Highload на стендах, собрались на свою небольшую DevRel Conf конференцию. Для меня это был третий Highload в этом году, после летнего, перенесенного с прошлого года и Питерского в сентябре. Может быть, поэтому доклады казались не столь привлекательными. А может быть просто так удачно складывалось, что в перерыве начинался интересный разговор, который не хотелось прерывать из-за доклада. Поэтому заметок будет не так много. В любом случае, конференция для меня получилась удачной, много общения, который, на самом деле, важнее докладов, и еще удалось поймать пару очень интересных мыслей, что бывает далеко не на каждой конференции.

Пара слов про конференцию в целом. Highload сильно меняется по составу. Это отметили еще этим летом, хотя отчасти это казалось естественным - все-таки предыдущий был в 2019. Но сейчас состав обновился снова. При этом участников было поменьше, чем летом, (2100 против 3000), но все равно много. А вот онлайн было сильно меньше, 836 против 4600 летом. Впрочем, за одним участником могут скрываться компании, плюс если от компании кто-то участвует, то потом записи оказываются доступными всем. Что еще интересно - на стендах добавилось много физической активности. Это началось в Питере, там на одном из стендов был скалодром, но вау-эффект вызвала другая активность: забрасывать в корзину мягкие ракетки, на него все два дня была постоянная очередь. Те, кто делают стенды поймали эффект, и сейчас на стендах было много такого. В общем, логично, мозгом люди работают и на работе много, так что простые физические развлечения привлекают.

Ну а теперь - заметки по конкретным докладам и темам.

Это - не название доклада, а мысль, которую я поймал на конференции, и сразу опубликовал на FB и в телеграме.

Слушая выступление Александра Зиза по мышлению и реплики слушателей, зафиксировал интересный конфликт школ. Есть школа СМД-методологии, которая говорит, что мышление возникает в ситуации, когда у вас есть проблема, с которой надо что-то делать, а вы не знаете, что именно. И есть школа нейрофизиологии, которая говорит что в стрессе блокируется поступление дофамина (и еще каких-то важных веществ) в кору головного мозга, что выключает возможность сложного мышления, остаются только типовые реакции. понятно, что противоречие не фатально, ты просто должен сначала И специально говорят о том, что сначала надо выйти из стресса, уже потом запускать мышление. Но при этом, получается, выйти из стресса надо, сохранив представление о проблемности ситуации - иначе мышления не будет.

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

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

А у меня в обсуждениях на конференции мысль сделала следующий шаг. Что такое любопытство? Это исследование ситуации, когда твоя внутренняя модель не объясняет что-то происходящее в мире, и ты исследуешь устройство мира, чтобы доработать свою модель. И тут мы неожиданно выходим на общее устройство эволюции. Анатолий Левенчук тут опубликовал фундаментальное изложение онтологии системного подхода, опираясь на современных авторов. Там, в частности, принцип свободной энергии Фристона, который определяет эволюцию для любых живых систем, включая социальные. У Левенчука это кратко, а подробнее можно прочитать объяснение здесь https://evan-gcrm.livejournal.com/1548097.html. Идея, что развитие идет в сторону уменьшения непредсказуемости, обусловленной разницей между внутренней моделью мира и реальным миром. А значит любопытство и последующее изменение своей картины мира как раз проявление этого закона. Кстати, неопределенность можно уменьшать и другим способом: переделывая мир в соответствии со своей картиной.

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

Буду еще об этом думать.

А для интересующихся про исследования об уменьшении креативности смотри, например, «Marshmallow Peter Skillman» (зефирный эксперимент), русское описание, например, здесь https://manage-it.livejournal.com/64382.html При чем в России ситуация хуже, она в топ 8-9 стран по развитости дошкольников, после началки — уже в 20, после ВУЗов — на 70 (это из выступления Алексея Нечаева на ПИР, смотри мой конспект). То есть система образования последовательно гробит живое в людях.

Пост на FB Круглый стол по инженерной культуре вызывал интересные мысли. Был тезис, из википедии: культура - это предписанный набор правил поведения с присущими переживаниями и мыслями, которые оказывают управляющее воздействие. Но вот потом разговор уходит именно в область правил, а мысли и переживания упускаются. А ведь именно это - принципиальный вопрос.

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

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

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

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

Кто культуру устанавливает? Зависит от контекста. Есть компания с культурой, туда приходит новый CTO с какими-то взглядами и целями, обычно есть цели что-то поменять. И ты начнешь менять культуру, свой mindset. но надо учитывать цели и взаимодействие с существующими.

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

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

Могут быть разные анклавы: в одном делают тесты, в другом - нет. Если СТО относится безразлично - так и будет. Вопрос - как распространить, изменяя культуру компании.

Пример плохого правила. Придумали timesheet, чтобы взаимодействовать через заказы. И люди стали несчастливы. Даль разъяснения, зачем необходимо - и люди написали быстрые трекеры, которые помогали быстро заполнять.

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

Все что делает бизнес - про деньги. Должен ли он инвестировать в культуру и в чем профит? Ответ - да. Это возможность создавать великие и инновационные продукты. И помогает хорошо масштабироваться людьми. Пример - все смотрят NPS сотрудников.

Интересный рассказ про DevOps процесс в большой компании БЕЗ выделенного отдела. 130 команд, специалисты - в командах, при этом SRE и DevOps может быть один на несколько команд. Важно, чтобы DevOps был в команде, потому что это - практика.

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

Принцип: стандартизация подхода по всем направлениям. Но! БЕЗ стандартизации инструментов и фреймворков. Только workflow и гейты. На слайдах были схемы процессов. Запрос на изучение, несколько ревью, потом RnD который выдаст MVP, а дальше вопросы внедрения в команде.

Работа с продуктами

• Усиление инженера
• DevOps внутри команды
• Обучение инженеров. Около 100 в очереди, около 60 обучаются. Внутри - потому что со спецификой компании. Обучение потоками.
• Программа - простая git, кубер, процессы: релизы, CI, CD; логгирование и мониторинг, устройство внутренних ЦОД.
• Зрелость команды для восприятия DevOps процессов:
  • Желание развиваться
  • Понимание движения компании: цифровизация, open source
  • Чек-лист зрелости команды - большой список практик по их использованию
• Метрики команд
  • Укомплектованность - по специализациям и уровням. Сбалансированность
  • Размер команд. DevOps - 1 на 5 разработчиков и не более 3 систем (зависит от квалификации)
  • Размер бэклога
  • TTM, Lead time и т.п.
  • Метрики процесса - из разных методологий

Выводы

• Что одной команде хорошо - другой не слишком
• C-level - это другое
• Все метрики хороши в меру, надо смотреть уместность
• Выстраивание любого процесса - это люди

Google берет в sre из разработчиков. У нас много из администраторов, опыта разработки нет, опыт конфигурирования. Но понимание кода - важно. Техническое собеседование - 60 тем (у фронтов - 175). В рамках темы с инженерами разного уровня обсуждают разное. В код не лезут, кейсы обсуждают, прошедшие и гипотетические. Похоже на собеседование. Есть люди в команде, и есть те, кто их направляет, имея более широкий кругозор.

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

1С пристуствует и выступает на Highload не первый раз, но уровень постепенно повышался, в этот раз компания была генеральным спонсором, а выступал Сергей Нуралиев. Цель, насколько я понимаю, в изменении восприятия разработчиками 1С как набора приложений, предназначенных исключительно для бухгалтерии и другого внедрения готовых решений, и восприятия сообществом 1С программиста как человека, который преимущественно конфигурирует готовое, быть может дописывая скрипты. Для этого 1С позиционируется как платформа для lowcode разработки произвольных решений, включая высокопроизводительные. Похожую смену позиционирования в свое время делал SAP, создавая SAP HANA, но там это было сделано совместно с созданием новой платформы разработки, так как решения SAP не имели общей платформы, а в случае 1С платформа была заложена в решение изначально, и она действительно позволяет создавать весьма широкий спектр разнообразных приложений, отличие лишь в уровне заготовок, которые есть для конкретных приложений. И это - не просто позиционирование. В платформе 1С 16 млн строк кода, в 1С:Предприятии 12 млн, а если бы не было lowcode - 30-50 млн. Сама платформа 1С написана на C++ и Java.

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

1. Loadbalancing. В бизнес-приложения разные вызовы отличаются на порядки: получение поля на форме или расчет производства вертолета - все идет как запросы от клиента. При этом нельзя пометить тяжелые запросы, потому что lowcode - мы не знаем, какой код вызывает запрос. Анализ кода, наверное, возможен - но это сложно, там цикл какой -нибудь по условию, и что? У них способ - пробные запросы. Переброс сеансов на разные сервера - стоит ли, кэши прогреты. Оценивают способность сервера.
2. Отказоустойчивость. Автоматический перезапуск, пользователи не должны ничего заметить.
3. Управляемые блокировки. Сначала использовали БД, но не удобно. Особое безобразие - эскалация, когда БД вдруг блокирует всю таблицу, когда решили, что пошла не тем путем. Задача - сделать параллельность везде, кроме случаев, когда бизнес-логика требует блокировки. Поэтому блокировки надо выносить разработчику на Lowcode - эту подробность нельзя скрыть.
4. Data Accelerator. Inmemory FimaDB. Очень реляционная, поддерживает мощный диалект SQL так, что можно переносить запросы из обычной БД. Поэтому администратор может просто включить акселератор.
5. Механизм копий - масштабируем читающую нагрузку. Тоже управляется администратором. Пока идет борьба за скорость заливки ,когда стартует копия. И перелив больших изменений. Но работает приемлемо.
6. Механизм фоновых заданий и регламентных задач. Это альтернатива многопоточным задачам и балансировки нагрузки.
7. Многопоточность - чтобы не было опасно и сложно.

Несмотря на сложности, задачи производительности решаются и вы можете использовать эти кейсы, чтобы привнести lowcode в вашии highload-приложения там, где это уместно. Каковы тут рекомендации?

• Помните, что часть приемов оптимизации становится недоступна. Зато можно оптимизировать движок, не трогая приложение, это - бонус.
• Не ковыряйте дырочки между lowcode и нижним уровнем. Если есть слой абстракции работы с данными - не давайте прямые запросы.
• Корпоративный и облачный профили нагрузки - разные. По взаимным зависимостям. У вас могут быть другие. Учитывайте типовые.
• Low - не только code. Еще развертывание и администрирование. Не упускайте ее.
• Безопасность. Закладывайте в модель сразу. И это защита не только от пользователей, но и от ошибок разработчиков
• Не экономьте на инструментах: мониторинг, логирование, диагностика

А я в заключении хочу сказать, что в мире разработки есть вот какая интересная задача: если вы делаете заказную систему, которая тесно взаимодействует с каким-либо 1С-решением, так что новая функциональность вашей системы поддерживается доработками в системе на 1С, например, для правильного учета новых сделок, то вам интересно включить обновление конфигурации 1С в общий цикл CI/CD на современном уровне, с развертыванием, автотестами на многих нодах и так далее. Я уже довольно давно слышал доклады от людей, которые так делали в своих разработках, но с тех пор технологии сменились. И, думаю,был бы интересны доклады, как это делать сейчас, может быть не от самой фирмы 1С, а от их франчайзи, которые решают такие задачи.

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

Доклад начался с истории подхода. Когда-то для вставки повторяющегося кода использовали макросы. Еще на ассемблере и PL/1, а потом на C. А еще в С есть pragma - это аннотации, которые влияют на генерацию кода. И все это - достаточно мощный механизм, который, отмечу, можно применять и сейчас, например, с помощью макропроцессора m4. А в языке Nemerle механизм макросов расширен, с его помощью реализован ряд конструкций самого языка - операторы if, for, foreach, while и так далее.

Но в целом для ООП-языков механизм макросов стал неудобным, потому что код, создаваемый через макросы не зависит от набора типов, в то время как для обычных методов есть развитые механизмы наследования и переопределения функций с поиском подходящей. Это может привносить сложные ошибки, при которых надо разбираться в структурах макросов. В то же время, задачи, которые решали с помощью макросов - сохранились. И для реализации адаптивного ООП было предложено аспектно-ориентированное программирование (АОП) и его реализация для Java в виде расширения AspertJ компанией Xerox PARC. При этом термин "аспектно-ориентированное программирование" они запатентовали. Но подход оказался удачным и развивался для разных языков, а название слегка меняли, чтобы обойти патентные ограничения.

Дальше был обзор способов реализации: код, связанный с аспектами можно добавлять до компиляции, во время компиляции, если компилятор позволяет такие расширения, и в runtime во время выполнения. И был обзор фреймворков для php, которые позволяют это делать с плюсами и минусами. А в заключении - примеры. Через аспекты можно делать логирование, кеширование, транзакции БД, профилирование, контроль доступа. Не подходит он для модификации основного функционала и подмены получаемых и возвращаемых значений, хотя его иногда пытаются для этого использовать, чтобы без модификации основного кода получить желаемое поведение. И вывод, который виден из примеров: в использовании АОП с готовым фреймворком просто, а под капотом - сложно, и эта сложность может неожиданно вылезти, если проявляется какая-то ситуация, на которую разработчики фреймворка не закладывались. Сложность - не повод, чтобы не использовать, но надо быть готовым столкнуться и отступить в конкретном случае.

Рассказ про решение частной задачи горизонтального масштабирования, в ситуации, когда обработка запроса клиента затрагивает данные, связанные с одним объктом, и если разложить данные по нодам, опираясь на ключи этих объектов, формируя на их основе правила шардирования, то все запросы к базе данных в рамках обработки одного запроса клиента пойдут только на одну ноду, и транзакцию тоже можно открывать только на ней. Для обработки запросов на каждой ноде поднимается свой PostgreSQL, вопрос - как сделать роутер, который диспетчеризует запросы. Они пробовали сделать специальный экземпляр PostgreSQL без своих данных, обращающийся к нодам через внешние таблицы или хуки, получилось неудобно или медленно.

Поэтому они написали свой роутер, который общается по протоколу PostgreSQL, к нему можно соединиться как к БД, он парсит запрос, определяет по условиям, на который какой из шардов отправить запрос и отпраяляет его. Шардирование - для всего, запросы, которые смешивают данные нескольких шард - запрещены. Транзакция открывается только на ноде, куда отправляются запросы. Роутеров можно поднимать много экземпляров для масштабирования и обеспечения устойчивости. Писали на Go, есть библиотека, которая умеет вызывать PostgreSQL-парсер.

Из принципа запроса на единственную ноду есть исключения:

• Можно создать таблицу сразу на всех шардах (может, и еще какие изменения в БД).
• Можно получить полный список ключей со всех шардов, только потенциально неконсистентный.

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

Кроме роутера есть координатор, которая умеет перемещать ключи между шардами для балансировки и обновляет данные на роутерах (пока идет перенос ключа - запросы ждут).

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

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

Первый доклад Антона Агеева "Программирование дронов — современная цифровая агрономия". Идея - замена сельхозавиации дронами. Они сильно дешевле. При этом, если дрон ведет автопилот, а не пилот по радиосвязи, то это дает гораздо больший эффект по стоимости и, как не странно, надежности. Программирование таких дронов - интересная ниша.

Второй доклад - Денис Мурвьев "Самый большой в РФ проект в области птицеводства по сбору информации с датчиков интернета вещей и другие интересные кейсы для сельского хозяйства". Речь шла о сборе информации с датчиков. Сейчас есть низкоэнергетический датчики, которые могут работать от одной батарейки несколько лет, устойчивы к жестким условиям и при этом передают информацию на десятки километров. У них одна антенна на 15 этаже на юге Москвы покрывает всю Москву и кусок Подмосковья, в частности датчики на птичниках в Истринском районе и принимает информацию с тысяч датчиков. Правда, передача медленная, 100 бит/с, чтобы батарейки хватало надолго, но датчику много цифр не надо. Решение включает hard - датчики и soft для них, хотели обойтись стандартным софтом, но не получилось по разным причинам.

Протокол радио - открытый, и api - открытый, если своя система - интегрируйтесь. Устройство занимает 50Гц, полоса 1.5кГц. Передает 50 байт. Протокол Loro дает большие помехи и know-how компании - качественный прием, чтобы услышать и датчик рядом, и слабый за 10 км, чтобы они не мешали.

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

Помимо этого проекта в докладе был обзор различных устройств и протоколов для датчиков, и кратко еще про несколько проектов. В области сельского хозяйства. Например, в контроле ситуации на полях чтобы управлять поливом, при этом на окрестные поля хватает одной антенны на втором этаже дома. Беспроводной забор - СВЧ-штора в комбинации с сухими контактами для электропастухов - до 50 метров и до 3 лет. Охрана поливалок: основаня стоимость - кабели, летом, пока едет их не снимают, а зимой - срезают, и они ставят датчики на размыкание кабеля.

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

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

В докладе был репрезентативный обзор разных типов инцидентов на материале публичных инцидентов в западных компаниях - потому что там это публикуется.

• Во-время не накатили патч после обнаружения уязвимости. Equifax. Компания предоставляла кредитные истории. Уязвимость в Apache Struts, найдена и патчена 7.03.2017 - было 4 месяца пропатчить. Не сделали, и 29/07/2017 сперли 145 млн. кредитных историй и 209 тыс. кредитных карт.
• Злоумышленник встроил backdoor в софт компании, через которую был получен доступ к их данным и в их сети. Компания SolarWinds - предоставляют сетевой доступ. Об инциденте стало известно 09.2019 стало известно об инциденте, но расследование установило, что backdoor встроили годом раньше. Встраивали по кусочкам, пользуясь тем, что в 2018 году компания просто опубликовала доступ к своему git-репозиторию с паролем SolarWinds123. И тут надо отметить вторую вещь: у компаний-клиентов срабатывал антивирус на backdoor, а техподдержка SolarWind порекомендовала просто его отключить, не разбиралась. И есть кейсы, когда для встройки backdoor устраиваются в компанию на работу, особенно если ее софт используется в каких-то более защищенных компаниях - государственных ,в военной сфере и так далее.
• Кейсы, когда злоумышленники получают доступ к информаструктуре компании и выводят ее из строя, требуя выкуп. Методы: учетная запись по умолчанию, уязвимости на серверах, фишинговые письма. Vastaamo psychtherapy center - финская клиника, зашифровали запись потребовали выкуп. Garmin - злоумыленник вывел из строя инфраструктуру, 4 дня пытались восстановиться, не получилось, выплатили 10 млн. выкупа. Westighoue Nuclear. 2017 Промшпионаж, злоумышленники выкачивали технологии. Тоже учетные данные для входа в паблике.

И другие.

А дальше рекомендации.

• Базовая гигиена разработки. Есть злоумышленники, которые пользуются
• Не игнорировать предупреждения. Есть коммюнити белых хакеров, которые ищут и предупреждают. С ними надо выстраивать взаимодействия и иметь контакаты.
• OpenSource - отслеживайте версии и бюллютени. Много вредоносных вставок. Хорошо если майнеры. Но встречаются бэкдоры полноценные, которые принесут дыру не только вам, но и клиентам
• Аккуратная публикация исходников. Часть на gihub выкладывают проект, а там - токены и секреты, и они используются. При этом они сталкивались, что подрядчик публиковал секреты, а злоумышленники пытались пройти к ним.
• Security должно быть хотя бы топ-5 приоритетов.

Разбирали кейс с одним вендором. В TeamCity - доступ у всех, включая девочку с ресепшн. У девочки в инструкции - открывать письма, где в заголовке "Генеральному директору из налоговой" - злоумышленник послал такое фишинговое письмо, захватил ее компьютер, а дальше - доступ в TeamCity и встройка вредносного кода.

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

Деврелы - это те, кто выстраивает отношения компании с разработчиками и другими сотрудниками, действующими и потенциальными, на рынке персонала. На Highload многие из них работали на стендах своих компаний, а после конференции, в субботу, провели свою конференцию в офисе VK, небольшую, человек на 100 (хотя могу ошибаться). Доклады были посвящены позиции деврела и приемам работы. Отметим, что отдельная позиция встречается не во всех компаниях, это может быть совмещено с какой-то другой работой, например, развитием внутренних сообществ или другим образом встроено.

Ксения Романова (DevRel-энтузиаст). Власть, бюджеты и хэдкаунт

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

Организационно встройка может быть разной.

• вертикально интегрируемый - все коммуникации с разработчиками
• проектный
• размазанный - все понемногу делают

Митапы и хабр - не основное. Основное - отношения с ценной аудиторией (разработчиков) чтобы достичь целей компании. А начать, если человек в компании новый - попросить у HR орг.схему и спросить, что недавно менялось. Новые люди часто ищут средства достижения целей.

Катя Фирсова (HRD, Altenar) Как “продать” DevRel бизнесу

Продавать DevRel надо не только бизнесу. Тимлид день стоял на стенде хайлоада - зачем? Если он будет думать, что это бессмысленно, то и толку от его присутствия на стенде не будет.

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

Тема "у всех есть, давайте сделаем" - тоже не работает.

Как надо - она не знает, но может рассказать, как делала она сама.

Parallels. Python breakfast, 4 года назад. Прошлась по всем граблям. Сказали "хочешь - развлекайся". 5тр на кофе. Выяснила, что это не обязательно - разработчики сами покупают себе кофе. Но разрешили уходить из офиса на завтрак, и еще брать евангелистов-разработчиков. Согласились, поэтому что раньше делала тоже самое для художников, рассказала историю.

Altenar. Компаний 40 человек в России, офис во Владимире (и еще в Европе 40). Отвечать за рекрутинг. 3-5 человек в год приходила, развивалась медленно, ребята не очень сильно хотели ездить на конференции - зачем? "О нас никто не знает", "Мы сидим во Владимире, делаем маленькое локальное, на конах - небожители". Предложила делать митапы - из предыдущего опыта. Руководство согласилось. Задачи: повысить узнаваемость, улучшить найм, вовлечь сотрудников в обучение, повысить лояльность. Стикеры, сообщество ИТ-разработчиков во Владимирами - нашли других разработчиков, человек 300, со своим чатом - живет.

Altenar - партнеры на конференции в Москве. Сразу предупредила, что людей не наймем. Но мы расскажем и мы будем не noname компанией, сможем говорить соискателям "погуглите про нас" - а это влияет на их решения. Узнаваемость.

При этом ребята, которые сидели в компании и не менялись - почувствовали интерес к новому. И оценили, что сами делают интересно, готовы выступить. Это вопрос внутреннего развития.

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

Измерения - есть всякие рейтинги, конверсии, резюме - они не слишком понятны бизнесу. Оно смотрит, но не слишком. Работает - когда ответ на собеседованиях "Слышали ли про Алтенар" рассказывают. Еще рейтинг hh, тоже работает. И отзывы во владимирских чатиков, что локальное может быть на уровне.

Сейчас 360 человек, 4 офиса сотрудников в России (Владимир, Питер, Нижний), Греция, Мальта (там было 40), Тбилиси и куча удаленных. Она попробовала сделать на Мальте. Там другой формат - сначала 1.5 часа бухла, потом начинается. Но она пробует.

Алина Романова (руководитель по развитию IT-бренда работодателя, Ozon) DevRel с чистого листа. Опыт Ozon

Направлению 1 год 4 месяца, с середины лета 2021. Год назад - на старте было 1200 человек, надо было стать 3500 на 31.12.2021 - в 3 раза. HR IT в вертикали СТО. HR IT - рекрутмент + бренд работодателя. Опрос лета 2021 - 21 место по опросу Экопси + Хабр. И надо было усиливать позиции. Все понимают, что деврел - вдолгую, но в три раза надо было вырасти быстро. Заказчик - CTO и его подразделения.

Приоритеты

• Стек технологий - бешеный. Но есть приоритеты Go, C#, QA automation. Сильные сообщества в компании.
• Уже было 1.5 человека: блог на хабре, один стенд на хайлоад, митапы, фирменный стиль придумали сами сотрудники, мерч.
• Добавили: работа с авторами opensource проектов, было в загоне, внутренние сообщества, Ozon Tech All Hands - каждый месяц встречи СТО и директора
• 1 Дизайнер фирменного стиля, 4 деврела, 1 SMM, 2 внутриком.
• Два направления: внутреннее сообщество (лояльность и коммуникация в команде митапы, встречи комитетов, втречи обмена опытом), сообщество снаружи (узнаваемый и привлекательный работодатель - понятный набор инструментов, просто параллельно)

Ключевые компетенции: Events, Коммуникации, Тексты. Бэкграунд членов команды - разный, организация конференций, рекрутмент, маркетинг, дизайн. Было разделение ответственности - раскидывали активности 4-5 штук, в презентации была схема. 1й - внутри, 2й и 3й - внешнее, 4й - текстовый. Результат - 292 спикера, 51 автор, 21500 подписчиков на хабр, 3600 tg, 7000 vk - без бюджета, классный контент. На конец 2021 было 4000 человек, и поднялись на 3 строчку бренда работодателя. Больше всего людей - видели в телеграме и соцсети и хабр. И посевы в сообществах, когда зовут и так далее. Периодичность - раз в неделю на хабре. А автор лучшей статьи - макбук.Сообщества - живых 4, некоторые еще - периодами. Есть зона роста...

Антонина Татчук (редактор, YADRO) + Елизавета Швец (Dodo). Компетенции в редакции технобренда

В презентации была карта компетенций для создания статей и выступлений, опубликованная в miro. Компетенций много, 63 штуки, а дальше надо как-то поделить ответственность. Ну или просто понимать, что ты не все делаешь хорошо. Тут как с картой компетенций тимлида - их тоже много, и на одном человеке собрать не реально, но в команде должны быть. Не все компетенции нужны сразу, это зависит от объема работы, в начале можно ограничиться небольшим набором. Но даже если выпускаешь одну статью в неделю - контент надо разумно планировать, учитывать целевую аудиторию и так далее. Часть компетенций можно аутсорсить, например, в пиар агенство.

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

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

Анастасия Распопина, Community Manager из Postgres Professional. Экзотические навыки для DevRel: от журналистского расследования до поэзии

Как без технического бэкграунда войти в круги разработчиков. 10 лет в ИТ-маркетинге, из них 5 - СУБД. Из достижений - идеи докладов на экспорт: завернуть доклад DBA так, что брали за рубежом, удачные темы - 13к хитов в месяц, техноюмор.

Как этого достигнуть? Базовые компетенции были в докладе Антонины Ткачук. Но есть дополнительные навыки.

• Надо заслужить уважение разработчиков, они не любят помогать тупым.
• Надо уметь подстраиваться - тебе же что-то надо от людей
• Надо стать интересным, чтобы им было интересно с тобой взаимодействовать, fun to work with

Как убедить интроверта, который публичность не любит, выступить.

• Лояльность компании - не продается. Он видит себя как белку в колесе или как сизифа, и дополнительную активность как лишнюю нагрузку.
• Работает "не для себя стараешься, а для резюме своего" - бренд не только компании, но и личный. Только начальнику надо сказать "спокойно, так продается", а на уход из компании это влияет слабо - люди уходят по другим причинам. Хотя, конечно, это может вскрыть ситуацию "я сильно недооценен" - но не надо недооценивать людей.

Подстройка. "Я ничего не понимаю" - не работает, идет реакция "и не поймешь". А вот "Я в последний раз писала калькулятор в школе, объясни" - тут есть шанс, потому как он видит ,что какая-то база есть.

Как узнать кто про что может рассказать? Если в open space - нет проблем, уши открыты, заполняешь Excel. Удаленка - не работает. Ее спасает диплом по журналистскому расследованию.

• Включенное наблюдение
• Наведение справок у коллег
• Поиск цифрового следа - в сообществах и форумах
• Эксперимент - анкетирование через HR. Например, посоветовать опрос кто знает и чему хочет научиться.

Так были найдены возможности для докладов

• Миллион запросов в секунду. Конкурирующие СУБД ни разу вместе не делали - а тут сделали сравнение.
• MySQL - чек лист для новичка. Его оказывается не было - сделали доклад из качественных ссылок.

Почти любое образование можно использовать. Филолог - креативное партнерство. Вы уже не филолог, а партнер. Вычитать CV, биографию, документ, подсказать как правильно написать. Вычитала презентацию - получила работу. Если занималась эвентами - подсказать место для отдыха или свадьбы.

Склонность к волонтерству. У senior решена проблема денег. Но они думают про самоактуализацию, есть самые разные связи во всяких местах. Только надо не перебарщивать - выгорание.

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

Придуманные названия из поэзии: Ужимай и властвуй, Жизнь и удивтельные приключения бага... Эксперименты на себе. Организовать пространство митапа, повысить комфорт разработчика в публичном поле и т.п.

Разбивай биографию на байки. То, что сеньоры тебя уважают - самая важная метрика.

Михаил Попов (Альфа-Банк). C какими задачами в Альфа-Банке приходят к Developer Relations, и как мы выстроили процесс взаимодействия с бизнесом

Event-management с малых мероприятий до концертов, потом Frontend и CPO. IT HR бренд в HR, 2 человека. Работный сайт, конференции, и еще для скрам-мастеров. Надо определить для кого. До этого HR бренд помогал 2-3 центрам экспертизы. Тут рынок в целом. digital.alfabant, Хабр, youtube теперь vk - объединили в одну системную работу. Стратегия: Альфабанк - технологичный банк.

Завели в Notion, очень красивый для команды. Внесли все планы. И решили для каждого центра экспертизы - выгрузку по фильтру. Например, для аналитиков. Мероприятия, большие интересные. И рассказывали о себе внутри - охватить все центры экспертиз. Чтобы к ним приходили с заказами. После внутренней рекламы Стало приходить слишком много запросов. Фильтр по стратегию и соотнесение с рынком. А еще - уровень вовлеченности подразделения, у них мало ресурсов, подразделение-заказчик должно быть партнером.

В 1-2 Q 2022 составляли планы сами, в 3-4 Q 2022 составляли планы с Заказчиками. И это изменение - центр экспертизы не ставит задачу, а как партнеры, которым мы советуем. Если задача "давайте срочно сделаем митап" - вопросы про цели и срочность.

Ведут бэклог в notion и кажется, что все понятно. Но этого не хватает, приходят за статусом. Подумали про инструменты, как доносить задачи. И сделали стратегию развития для каждого центра экспертизы (не Альфа-банк технологичный банк, а DataScience ...). И собрали в Excel. Notion оказался для партнеров сложным инструментом. И цветовое различие по строкам. Регулярный статус. Был от запроса, сейчас с каждым центром - регулярные синки раз в 1-2 недели в зависимости от потока работ, и обсуждаем статус в Excel. Коррекция процессов с учетом персональной стратегии центров компетенций.

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

В 1 квартале 2022 была задача нанять 2000 ИТшников. И деврел работал в партнерстве с ИТ - OneDayOffer. B метрики были. А сейчас - найм выполнен, и другой фокус - на помощь центрам экспертизы.

Адель Макашева, DevRel из Газпромбанка. Как продюсирование спикеров изменило мое отношение к карьере и контенту

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

Надо не выводить одних и тех же. Смотреть, как подсвечивать на сцене, чтобы он притянул других мастодонтов ИТ.

Виталий Левченко (Основатель, Failover Bar). IT бар, или как не надо делать деврел

Виталий делал последний IT Global Meetup в Питере весной 2019 года. Вообще IT Global Meetup - такое замечательное мероприятие, проходившее несколько раз в год, которое проводит сообщество сообществ Piter United, объединяющее около 30 сообществ. Обычно участвуют 15-20 сообществ, каждое делает свой островок, все треки идут параллельно, а общее количество участников - 1000-1500. В том, о котором говорил Виталий, я не участвовал, расписание не позволяло, но вообще я знал и участвовал в ITGM с 2016 года. Очень жаль, что ковид прекратил эту историю.

И у Виталия возникал идея создать площадку для постоянного общения ИТ-шников в баре. Для начала он не хотел открывать свой бар, они сделали договорились с баром и IT Speed Dating, получили 40 регистраций при анонсе за неделю, люди пришли. Сделали еще несколько встреч. Приходят. Но все-таки бары не умеют коммуницировать с людьми, поэтому давайте сделаем свой бар.

Идея: будет бар, он будет окупаться как бар. Реклама - ивенты сообществ, свое сообщество, коворкинг, доп.площадка конференций, площадка и партнер для ИТ-компаний. Более года искали площадку, чтобы уложиться в деньги, но чтобы было рядом с метро в центре, 200 м залы, зона для митапов 100 человек, лаунж-зона, барная зона. Сняли в декабре 2021, открылись в марте 2022 без кухни, оно встретило отклик: людям хочется идти к своим, в июне появилась кухня. Я там был в сентябре, когда ездил на Saint TeamLead и Highload, ходили туда после afreparty и после конференции, обстановка довольно приятная. Бар Failover рядом с Василеостровкой Правда, сейчас будущее непонятно, мобилизация сильно сократила посещаемость.

Дальше в докладе был опыт работы с сообществами. Открытые сообщества и сообщества компаний - это сильно разное. Открытые - горизонтальные связи, без внешней помощи, есть цель. Цель и культуру задают лидеры. И компании не умеют работать с открытыми сообществами. Что хотят сообщества, что хотят лидеры, что мотивирует продолжать, как помочь в создании? Лидеры хотят известности и влияния. Не денег, коммерческие комюнити - это другое. Хотят быть частью чего-то крутого и поделиться экспертизой. Сообщества хотят тусовок, единомышленников, ощущать значимость. Площадка, реклама (не всем), драйв и движ - ощущение, что живые. При этом у них бывает большой запрос, например, на качественные трансляции: если хайлоад делает, почему вы не можете? Участники сообществ хотят Заботаы, ожидают теплоты от окружающих, часто именно заботы от компаний им не хватает.

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

Помочь создать. Фреймворк мероприятия, дружба с тематическими онлайн - живые сообщества, чат, много движа. Еще - амбициозный и геперактивный организатор. Это - обязательно. Без этого не едет. В 2016-2017 работало по-другому. Я выскажу гипотезу, что это могло быть влияние Piter United: он сильно снизил порог входа, это было видно по ITGM: если 3-5 человек заинтересовались новой темой, то они легуко могли сделать островок на готовой инраструктуре встреч и привлечь заинтересованных. Монетизировать сообщества - никак. Хотя в 2019 как-то работало.

В чем сложность с баром? Ты - собственник, и это сильно грузит. В планах было отдать управление баром наемному менеджеру, менеджер-профессионал есть, но он совсем не так относится к деньгам, как относится собственник. А в результате если у тебя фул-тайм работа, ты собственник и есть 3-5 мероприятий в неделю - выгоришь. Хотел делегировать организацию мероприятий, деврел, но тоже не получилось, исполнители не справляются, а для высокого уровня - не хватит денег, есть 50-60тр в месяц, иначе экономика бара не сходится.

Такая интересная история.

В заключении поделюсь наблюдением, которой Виталий сделал в баре. Девушке на ИТ-мероприятиях надо специально коммуницировать, что она - разработчик или имеет другую техническую специализацию. По умолчанию всех девушек воспринимают как HR. Что не оправдано: HR на встречах обычно только половина.