TeamCity-фея🧚‍♀️ или деплой души🌸

Была сапожником без сапог, но теперь ситуация исправлена - ловите мое первое интервью 🎙
#интервью@teamcity_fairy

Как виртуалка из Англии пришла за вашим TeamCity🚌

Немного хулиганский пост выше об одном очень интересном кейсе взлома ТимСити🫡.
От Яна - одного из героев проекта интервью людей с необычной биографией. У него, кстати, тоже теперь свой канал про девопс и боль поиска работы. Возможно, этот канал сможет дать почувствовать сильному специалисту, оказавшемуся в долгом поиске работы, что он не одинок💔 🤗
Подписывайтесь!
#техническое@teamcity_fairy
#интервью@teamcity_fairy

Довелось попробовать себя в новом деле - участие в организации #proitfest🔥
Извлекла полезную мысль из этого опыта: не нужно пытаться избежать проблем, нужно быть готовой их решать:) С таким настроем не тратишь силы на сожаления и чувство вины из-за того, что что-то пошло не так, а направляешь всю энергию на решение задач:)
Впервые была на мероприятии такого формата, где очень-очень много спикеров в маленьких уютных комнатах, и взаимодействие со слушателем идёт в режиме диалога. Это позволяет разглядеть тему под разными углами, и многие спикеры отметили, что в таком формате им было даже интереснее, чем выступать перед большим залом. Кстати, каждая комната была оформлена в своем прикольном стиле:)
Темы были самые разные: начиная от самых хардовых, заканчивая коучингом и психологией (внезапно, последние пользовались гораздо большей популярностью среди итшников, видимо очень актуально). В моей комнате много очень обсуждали влияние использования ии на психику работника. Да, "побочных эффектов" от него довольно много.
На заключительном докладе узнала кое-что новое про свой архетип (кто был, тот поймет;).
В целом, было очень много веселого неформального общения.
В общем, несмотря на большое количество одновременных задач в начале, с которыми нужно было как-то справиться, я осталась очень довольна этим днём🔥
Завершился день таким вот душем, как на фото ⛈️

Решила в этот раз разбавить контент чем-то весёленьким)
Тот самый сериал из детства 😍🚚

Как стать незаметным и зачем это нужно

Все знают о пользе заблаговременных мер по предотвращению проблем:

⬆️Настроить мониторинг и вовремя заметить и увеличить заканчивающиеся ресурсы
⏳Узнать о планируемых обновлениях смежных систем и подготовить к ним свою систему
🥹Заменить истекающие сертификаты
🕯️Исследовать утечку памяти

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

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


Поэтому, я считаю, что очень важно придумать способы:

📝Замечать профилактическую работу

🔥Мотивировать на нее
людей больше, чем на решение случившейся аварии


Возможные способы:

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

Самый лучший инцидент - тот, которого удалось избежать 🤩

А задача хорошего девопс-инженера - быть незаметным 🤩🌟🧿

Поделитесь, какой самый прикольный или серьезный инцидент вам удалось предотвратить?
#отношения_в_команде@teamcity_fairy
#процессы@teamcity_fairy
#best_practices@teamcity_fairy

Состояние потока или нейробиология сборок🧪🌟

Быстрая обратная связь от действия - одно из условий достижения состояния потока, в котором выше продуктивность и больше удовлетворённость от работы.

Выходит, быстрые сборки делают разработчиков счастливее?💗
Да, все благодаря дофамину.

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

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

Поэтому разработчики воспринимают свои успешные сборки как маленькие победы (хотя иногда и как большие, если отладка выдалась очень сложной🙈). И чем больше таких побед в течение дня, тем выше настроение, мотивация и энергия команды ☕️.

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

Что может помочь ускорить сборки:

✨ Кеширование зависимостей (у многих сборочных инструментов есть такая опция, но осторожнее с локальным кешом, он может менять состояние билд-агента)
✨ Грамотный dockerfile
✨ Разделять сборки на параллельные
✨ Запускать только нужные тесты и шаги у сборок (по условию, например)
✨ Позаботиться о производительности билд-агентов (мониторинг их ресурсов)
✨ Оптимизировать зависимости
✨ Следить за размером скачиваемых и выкладываемых артефактов сборок
✨ Не пересоздавать без необходимости тяжёлые сборочные и тестовые окружения
✨ Пересобирать только то, что изменилось

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

Выходит, CI/CD с точки зрения нейробиологии - не просто инструмент доставки кода. Это ещё и механизм, который поддерживает быстрые циклы предсказания и обучения, под которые человеческий мозг эволюционно очень хорошо приспособлен 🤩.

P.S. А моей маленькой победой с утра было осилить этот пост 🙈🙈
Но считаю важным писать об этом. Ведь мы обслуживаем не только системы, но и людей 🤗

А вы как ускоряете свои сборки? И было ли что-то сегодня, что принесло вам удовольствие от результата?🔥
#процессы@teamcity_fairy
#психологическое@teamcity_fairy
#техническое@teamcity_fairy
#best_practices@teamcity_fairy
#выгорание@teamcity_fairy

Когда чужая проблема постучалась в твой домик🏡

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

Что выбрать в такой ситуации? Указать ему на это и закончить общение?
Или же всё-таки выслушать странника, заварить ему чай с имбирем🧸, вместе покрутить волшебный шар🔮, подумать и найти решение? Иногда именно из таких разговоров "не по адресу" рождаются крутые неожиданные идеи.
К сожалению, правильный ответ на этот вопрос не такой уж очевидный, да и существует ли...

А может быть, если меня читает кто-то из лидов, хорошо когда в команде есть и те, кто выбирает первый вариант, и те, кто второй, и тогда наступает баланс?☯️

Пишите свое мнение в комментариях, как обычно принимаете решение в таких случаях:)
#отношения_в_команде@teamcity_fairy
#процессы@teamcity_fairy

Захотелось провести интерактив))) Расскажите в комментариях свои самые веселые или нелепые истории, связанные с работой🥳
Не обязательно прям с рабочими задачами, а можно просто, как что-то веселое творили с коллегами на работе/вне работы 🤩🌟
#забавное@teamcity_fairy

Тепло и уют на митапе по Architecture as code💚

Сходила на митап по Architecture as code, встретила там кучу знакомых, в тч среди организаторов, митап порадовал классной атмосферой!

Основная идея:
Хранить архитектуру в гите, прогонять проверки в CI, генерить диаграммы автоматически.

Много говорили про C4 модель - модель, которая рассматривает систему на 4-х уровнях (общее представление, компоненты, контейнеры(не путать с докер), код).
Рассматривали этот подход через метафору Google Maps, когда можно увеличить любой кусочек карты до нужной степени детализации🌖. И инструмент Structurizr для работы с этой моделью.

Другие идеи доклада:

🍎Полезно применять фитнес-функции - тесты, которые проверяют основные критерии корректной архитектуры системы.

📊Подход monitoring as code (когда метрики, алерты, дашборды описываются в виде кода) помогает сделать систему более наблюдаемой. Рекомендуется применять золотые сигналы Google (traffic, latency, errors, saturation).

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

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

И... на этом докладе произошла развиртуализация с Женя Янченко, одним из моих любимых авторов!🐈

И даже получила приятность про себя у Жени в канале:

А главное — на митапе я увиделась вживую с милейшей devops-инженером и TeamСity-феей Марией, проболтала с ней кофе-брейк и путь домой. Будто сто лет знакомы 😍

А вы практикуете такой подход?:)
#мероприятия@teamcity_fairy
#доклады@teamcity_fairy
#полезное@teamcity_fairy

Иду завтра на такой митапчик по архитектуре☺️
https://billing.timepad.ru/event/3926287/?utm_refcode=f2fb87a776f33de1e4c3ecdc45a44fffbc02f44c
#мероприятия@teamcity_fairy

Лучшие практики: о чем молчат в книгах📚

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

Пример 1 (чистый код)
Часто камнем преткновения являются написание чистого поддерживаемого кода и документация. Команда, где это делается, будет работать эффективнее. Но многие люди на это забивают, потому что каждый стремится показать свою собственную эффективность, а она будет выше, если не думать об удобстве других коллег + у этих самых коллег она будет при этом ниже. Также люди очень любят получать дофамин от сделанных задач💥. И получать его как можно быстрее. Поэтому этот красивый и логичный процесс, где забота о сопровождаемости кода удешевляет его стоимость обслуживания, часто оказывается работающим только в книгах.
А на практике нуждается в доп работе с мотивацией людей, чтобы им было выгоднее его соблюдать, чем игнорировать❤️.

Пример 2 (работа с инцидентом)
Вроде бы все продумано и прописано, но люди все равно предпочитают действовать иначе.
Дело может быть также в невыгодности соблюдения такого процесса. Создавая процессы работы с инцидентами, важно учитывать возможные страхи и опасения исполнителей (можно даже провести анонимные опросы). Продумывать меры по снижению подобных рисков. Стараться делать процесс таким, чтобы его соблюдение было в личных интересах❤️ большинства.

Какие это могут быть страхи
🥺Страх быть виноватым (чтобы его избежать, нужно не просто объявить всем, что у нас blameless culture, а модерировать общение)
👩‍💻Страх появления доп обязанностей
💼Страх появления новой зоны ответственности
⌨️Предпочтения в коммуникации (кому-то тяжело участвовать в созвоне и проще писать короткие статусы, кому-то проще говорить, чем писать)
⏳Страх дедлайнов по другим задачам ("сделаю все по процессу по инциденту - пропущу дедлайны по основной работе")
🛜Недоверие к коллегам (самый умный синьор может бояться подключать к проблеме других, чтоб не испортили ничего)
❓Страх, что начнут дергать вопросами в условиях нехватки времени
📜Страх делиться и документировать знания (вдруг заменят)

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

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

А вы сталкивались в своей работе с процессами, которые не соблюдаются по психологическим причинам? Как решали проблему?
#best_practices@teamcity_fairy
#психологическое@teamcity_fairy
#процессы@teamcity_fairy
#личный_опыт@teamcity_fairy
#отношения_в_команде@teamcity_fairy

Путь в девопс с кафедры пастора: через кризис, Linux и личные границы ⛪️

Сегодня история о человеке, который прошёл путь от руководителя в протестантской церкви до DevOps-инженера.

Роман ещё с юности стал заниматься протестантским молодёжным клубом, а со временем дорос до старшего пастора Владимирско-Ивановской области.

Но IT всегда было в ❤️ нашего героя. В перерывах между организацией больших церковных мероприятий, удавалось читать книги по ит, что со временем позволило заняться фрилансом на php.

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

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

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

Что решили посоветовать новичкам:
📚Нужно быть готовым к постоянному обучению (Linux, docker, virtualization, kubernetes, observability, Iac).
💝Помогают книги, курсы, ютуб, чтение документации.
🧠 Помогают Gemini, codex, Claude. Но важно использовать их для первичного решения, а докручивать решение уже по документации, тк она более актуальна.
🗞 Любознательность и любовь к новому - большое преимущество.
👩‍💻 Linux - фундамент.
🔧 Полезно осваивать навыки траблшутинга.
💘 Общайтесь с коллегами, спрашивайте у них помощь.

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

В комментариях можете задавать Роману вопросы;)

P.S. Если вы тоже хотите поучаствовать в этом проекте, можете писать мне в лс)
#интервью@teamcity_fairy
#личный_опыт@teamcity_fairy
#полезное@teamcity_fairy

Завтра еду на DeckhouseConf!🔥
https://deckhouseconf.ru/
Интересно, едет ли кто ещё из подписчиков)
#мероприятия@teamcity_fairy

Linux на чай: из официанта и рекламы в девопсы 🍰☕️

Еще одно вдохновляющее интервью состоялось у меня недавно!🤗
Герой предпочел остаться анонимным, но с энтузиазмом и любовью к своему делу преодолел путь в ит, который оказался совсем не прямым.

Также, как и в предыдущем интервью, гость этого загорелся ит еще в школе.
Главным мотиватором было желание автоматизировать задачи, которые не хочется делать самому (тут совпало с моей теорией про обучение, что это один из наиболее эффективных методов получать скиллы в ит). Также настраивал сети на компах в школе 🌐.

Получил тех образование, но после универа работал официантом☕️ и в рекламе. Чтобы облегчить себе жизнь в рекламе, приходилось искать способы автоматизации задач. Так потихоньку появлялись знания. Про девопс узнал случайно, и записался на стажировку. Был период, когда потребовалось не работать, и обучаться дома фулл тайм. Постепенно дорос до крупной компании. Опыт работы официантом и в рекламе помог научиться видеть места, которые нужно автоматизировать или оптимизировать.

Жизненные выводы и советы новичкам:
-  Делать бекапы!💻
-  Опыт и хорошие практики усваиваются лучше, когда наступаешь на грабли 😈
-  Пробуйте, экспериментируйте. Но осторожно!🍾
-  Выбирайте технологии для обучения, отталкиваясь от списка актуального на хх
-  Не бойтесь просить о помощи
-  Ходите на стажировки от универа (сама с них начинала, кстати, лучшее время было)
-  Ходите по собесам, а не только теорию учите
-  Когда читаешь книгу или доку, важно задавать себе вопросы: "а что будет, если сделать иначе" 📚

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

Вот такой интересный путь получился!
Можете в комментариях задавать главному герою вопросы, а я опубликую ответы 🤗
#интервью@teamcity_fairy
#личный_опыт@teamcity_fairy
#полезное@teamcity_fairy

Конфетная дилемма🍰

Ела недавно пирожные с низким содержанием сахара, и вот, о чем подумала.
Когда работаешь в офисе, иногда сталкиваешься с такой проблемой, что клиенты за хорошую работу угощают пироженками, мороженками, конфетами🎂🍦🍬.
И вот, вроде бы и отказаться неудобно, ведь это в благодарность.
Но и фигуру жалко🙈
Поэтому, если меня вдруг читают разработчики или тимлиды, то девопсам очень приятно и важно, когда их работу ценят, но выражать это лучше на словах, а не в конфетах💗 .

Поделитесь, а вы сталкивались в работе с углеводными атаками со стороны клиентов?) Как решали дилемму?)
#забавное@teamcity_fairy
#отношения_в_команде@teamcity_fairy