125
Каждый сходит с ума по-своему, или пробую в тг-канал о психологических аспектах практик devops https://t.me/teamcity_fairy
Была сапожником без сапог, но теперь ситуация исправлена - ловите мое первое интервью 🎙
#интервью@teamcity_fairy
Довелось попробовать себя в новом деле - участие в организации #proitfest🔥
Извлекла полезную мысль из этого опыта: не нужно пытаться избежать проблем, нужно быть готовой их решать:) С таким настроем не тратишь силы на сожаления и чувство вины из-за того, что что-то пошло не так, а направляешь всю энергию на решение задач:)
Впервые была на мероприятии такого формата, где очень-очень много спикеров в маленьких уютных комнатах, и взаимодействие со слушателем идёт в режиме диалога. Это позволяет разглядеть тему под разными углами, и многие спикеры отметили, что в таком формате им было даже интереснее, чем выступать перед большим залом. Кстати, каждая комната была оформлена в своем прикольном стиле:)
Темы были самые разные: начиная от самых хардовых, заканчивая коучингом и психологией (внезапно, последние пользовались гораздо большей популярностью среди итшников, видимо очень актуально). В моей комнате много очень обсуждали влияние использования ии на психику работника. Да, "побочных эффектов" от него довольно много.
На заключительном докладе узнала кое-что новое про свой архетип (кто был, тот поймет;).
В целом, было очень много веселого неформального общения.
В общем, несмотря на большое количество одновременных задач в начале, с которыми нужно было как-то справиться, я осталась очень довольна этим днём🔥
Завершился день таким вот душем, как на фото ⛈️
Как стать незаметным и зачем это нужно
Все знают о пользе заблаговременных мер по предотвращению проблем:
⬆️Настроить мониторинг и вовремя заметить и увеличить заканчивающиеся ресурсы
⏳Узнать о планируемых обновлениях смежных систем и подготовить к ним свою систему
🥹Заменить истекающие сертификаты
🕯️Исследовать утечку памяти
И так далее.
Но, на практике, зачастую такая работа остаётся незаметна, тк эти изменения проходят для системы гладко, не приводя к остановкам и сбоям. Что очень хорошо с точки зрения эффективности для команды в целом.
Но вот парадокс: это оставляет работу инженера незамеченной, что плохо влияет на восприятие эффективности его работы со стороны.
По этой причине, в некоторых командах начинает распространяться культура дождаться серьезной заметной проблемы, и только тогда начинать ее решать. Что обходится гораздо дороже.
Поэтому, я считаю, что очень важно придумать способы:
📝Замечать профилактическую работу
🔥Мотивировать на нее
людей больше, чем на решение случившейся аварии
Возможные способы:
➡️ Вести табличку с действием, автором и предотвращенным ущербом
➡️ В постмортемах фиксировать, какие меры можно было бы предпринять, чтобы избежать инцидента
➡️ Отмечать на ретро тех, кто что-то предотвратил
➡️ Поощрять нахождение инженерами новых превентивных мер и рисков
➡️ Рассказывать об устраненных технических рисках так же, как о новых фичах
➡️ Рассказывать всем о важности этого и учиться замечать такие вещи
Самый лучший инцидент - тот, которого удалось избежать 🤩
А задача хорошего девопс-инженера - быть незаметным 🤩🌟🧿
Поделитесь, какой самый прикольный или серьезный инцидент вам удалось предотвратить?
#отношения_в_команде@teamcity_fairy
#процессы@teamcity_fairy
#best_practices@teamcity_fairy
Когда чужая проблема постучалась в твой домик🏡
Наверное, каждый хоть раз сталкивался с таким выбором. Представим ситуацию. Ты сидишь в лесу у костра своего проекта🪵. И тут к тебе приходит путник, который устал искать решение своей задачи. Но этот вопрос не имеет к твоему проекту никакого отношения...
Что выбрать в такой ситуации? Указать ему на это и закончить общение?
Или же всё-таки выслушать странника, заварить ему чай с имбирем🧸, вместе покрутить волшебный шар🔮, подумать и найти решение? Иногда именно из таких разговоров "не по адресу" рождаются крутые неожиданные идеи.
К сожалению, правильный ответ на этот вопрос не такой уж очевидный, да и существует ли...
А может быть, если меня читает кто-то из лидов, хорошо когда в команде есть и те, кто выбирает первый вариант, и те, кто второй, и тогда наступает баланс?☯️
Пишите свое мнение в комментариях, как обычно принимаете решение в таких случаях:)
#отношения_в_команде@teamcity_fairy
#процессы@teamcity_fairy
Тепло и уют на митапе по Architecture as code💚
Сходила на митап по Architecture as code, встретила там кучу знакомых, в тч среди организаторов, митап порадовал классной атмосферой!
Основная идея:
Хранить архитектуру в гите, прогонять проверки в CI, генерить диаграммы автоматически.
Много говорили про C4 модель - модель, которая рассматривает систему на 4-х уровнях (общее представление, компоненты, контейнеры(не путать с докер), код).
Рассматривали этот подход через метафору Google Maps, когда можно увеличить любой кусочек карты до нужной степени детализации🌖. И инструмент Structurizer для работы с этой моделью.
Другие идеи доклада:
🍎Полезно применять фитнес-функции - тесты, которые проверяют основные критерии корректной архитектуры системы.
📊Подход monitoring as code (когда метрики, алерты, дашборды описываются в виде кода) помогает сделать систему более наблюдаемой. Рекомендуется применять золотые сигналы Google (traffic, latency, errors, saturation).
🟢У компании должен быть тех радар, с которым сверяются используемые технологии, чтобы они соответствовали имеющимся в компании компетенциям.
В целом, все крутится вокруг одной мысли: архитектура должна жить в едином месте в системе контроля версий в виде кода и регулярно автоматически проверяться. Проверка архитектуры дешевле проверки кода. Выходит, архитектуре тоже нужен свой пайплайн:)
И... на этом докладе произошла развиртуализация с Женя Янченко, одним из моих любимых авторов!🐈
А вы практикуете такой подход?:)
#мероприятия@teamcity_fairy
#доклады@teamcity_fairy
#полезное@teamcity_fairy
Лучшие практики: о чем молчат в книгах📚
Часто нам кажется, что если процесс логичный и правильный, то он будет работать, ведь все хотят наилучший результат для команды и делать свое дело хорошо (разве кто-то скажет про себя иначе?).
Но, в реальности, подобные красивые процессы разбиваются об индивидуальную мотивацию людей💔.
Пример 1 (чистый код)
Часто камнем преткновения являются написание чистого поддерживаемого кода и документация. Команда, где это делается, будет работать эффективнее. Но многие люди на это забивают, потому что каждый стремится показать свою собственную эффективность, а она будет выше, если не думать об удобстве других коллег + у этих самых коллег она будет при этом ниже. Также люди очень любят получать дофамин от сделанных задач💥. И получать его как можно быстрее. Поэтому этот красивый и логичный процесс, где забота о сопровождаемости кода удешевляет его стоимость обслуживания, часто оказывается работающим только в книгах.
А на практике нуждается в доп работе с мотивацией людей, чтобы им было выгоднее его соблюдать, чем игнорировать❤️.
Пример 2 (работа с инцидентом)
Вроде бы все продумано и прописано, но люди все равно предпочитают действовать иначе.
Дело может быть также в невыгодности соблюдения такого процесса. Создавая процессы работы с инцидентами, важно учитывать возможные страхи и опасения исполнителей (можно даже провести анонимные опросы). Продумывать меры по снижению подобных рисков. Стараться делать процесс таким, чтобы его соблюдение было в личных интересах❤️ большинства.
Какие это могут быть страхи
🥺Страх быть виноватым (чтобы его избежать, нужно не просто объявить всем, что у нас blameless culture, а модерировать общение)
👩💻Страх появления доп обязанностей
💼Страх появления новой зоны ответственности
⌨️Предпочтения в коммуникации (кому-то тяжело участвовать в созвоне и проще писать короткие статусы, кому-то проще говорить, чем писать)
⏳Страх дедлайнов по другим задачам ("сделаю все по процессу по инциденту - пропущу дедлайны по основной работе")
🛜Недоверие к коллегам (самый умный синьор может бояться подключать к проблеме других, чтоб не испортили ничего)
❓Страх, что начнут дергать вопросами в условиях нехватки времени
📜Страх делиться и документировать знания (вдруг заменят)
Ментальная нагрузка❤️
Также важно думать о ментальной нагрузке людей. Сможет ли человек работать эффективно над плановой задачей после решения серьезного инцидента? Или в условиях постоянного переключения контекста из-за маленьких sla на ответ? Или после плотного дежурства? Сможет ли человек вовлеченно координировать инцидент и во время реагировать, если у него неотменяемый дедлайн по другой задаче?
Подобные соображения выходят за рамки инженерного мышления🧠, поэтому их порой сложно учитывать людям с техническим образованием. И о подобном часто не пишут в книгах и статьях про лучшие практики и процессы📚.
А вы сталкивались в своей работе с процессами, которые не соблюдаются по психологическим причинам? Как решали проблему?
#best_practices@teamcity_fairy
#психологическое@teamcity_fairy
#процессы@teamcity_fairy
#личный_опыт@teamcity_fairy
#отношения_в_команде@teamcity_fairy
Завтра еду на DeckhouseConf!🔥
https://deckhouseconf.ru/
Интересно, едет ли кто ещё из подписчиков)
#мероприятия@teamcity_fairy
Конфетная дилемма🍰
Ела недавно пирожные с низким содержанием сахара, и вот, о чем подумала.
Когда работаешь в офисе, иногда сталкиваешься с такой проблемой, что клиенты за хорошую работу угощают пироженками, мороженками, конфетами🎂🍦🍬.
И вот, вроде бы и отказаться неудобно, ведь это в благодарность.
Но и фигуру жалко🙈
Поэтому, если меня вдруг читают разработчики или тимлиды, то девопсам очень приятно и важно, когда их работу ценят, но выражать это лучше на словах, а не в конфетах💗 .
Поделитесь, а вы сталкивались в работе с углеводными атаками со стороны клиентов?) Как решали дилемму?)
#забавное@teamcity_fairy
#отношения_в_команде@teamcity_fairy
Ищу супергероя🔥
Друзья! Решила провести необычный социальный эксперимент. Впервые у меня такое, не судите строго) Но важно приобретать новый опыт!
Ищу человека, который перешел в сферу девопс из какой-то нетипичной для итшника сферы, которая вообще никак с этим не связана, чтобы...
Взять интервью! 📝
О пройденном пути, о том, что пришлось преодолеть, какие были этапы, как все получилось, какие были сложности и подводные камни. Чужой опыт всегда полезен. Также уверена, что мой канал читают и начинающие девопсы, и им было бы интересно узнать путь с нуля. А нетипичная предыдущая сфера деятельности сделает этот рассказ ещё более вдохновляющим и интересным!💖
Интервью, конечно, размещу на этом канале. Не бойтесь: никаких съемок, интервью чисто текстовое, можно даже пообщаться без камеры) Можно и встретиться лично: с меня чай/кофе☕️, шоколадка и хорошее настроение!
А также рассказ о тебе на мою хоть и небольшую, но очень душевную аудиторию❤️.
Если пожелаешь, можно сохранить анонимность🥸. Если интересно, пиши сюда @topmarie, обсудим подробности 🤗
Дайджест канала
Решила создать подборку самых популярных и интересных постов этого канала для новеньких посетителей 🤗
Пост-приветствие и пост-структура
Самые популярные посты:
Почему-то самый просматриваемый пост, хотя и не самый любимый
Один из самых залайканных постов: про обучение
Распознавание эмоций и немного крови, или один из самых забавных постов
Набравшее очень много лайков мнение прожарщика тг-каналов об этом канале
Единственный пока пост в экспериментальном сказочном формате 🦋
Посты-ответы на анонимные вопросы:
Сам анонимный опросник
Должен ли менеджер разбираться в той области, которой управляет
Гендерный вопрос: как выживают девушки в девопс 💅
Роадмап для девопса
Посты для рефлексии:
Один из самых философских постов о поиске смысла
Пост о том, что связывает психологию и devops, в целом раскрывающий смысл этого канала 🦋
Посты о том, как справляться с жизнью:
Применение практик инфраструктурных команд в борьбе с жизненным хаосом
Опасные ловушки современного мира: что общего между криптой, йогой и ит
О чем нас забыли предупредить про цели по smart
Как не дать иишке свести тебя с ума 🧠
Отношения в команде и навыки общения:
Шоколадка "умею дружить с коллегами" или тонкости работы с подсознанием 🍫
О корреляции между навыками общения и prompt engineering
Пост о команде, которой есть, что скрывать
Практические посты:
Готовим вкусный пайплайн: как собирать требования
Лайфхак для изучения паттернов программирования 🐄
Environmental drift, или сказка о том, как окружения разъехались
Соцопрос о полезности карьерного телеграм-бота
Никто больше не использует TeamCity: правда ли это?
Перемотай этот пост наверх, чтобы увидеть дайджест постов с самого начала;)
#полезное@teamcity_fairy
Вот что думает о моем канале @ScratchAuthorEgoBot - бот прожарки тг-каналов)
"Называть команду инфраструктуры «феями» в индустрии, где люди привыкли изъясняться матом и логами — это либо высшая степень троллинга, либо очень смелый эксперимент по внедрению «уютности» там, где горит прод." (с)
Вообще да, действительно как-то хотелось разбавить суровую обстановку ☕️
#забавное@teamcity_fairy
Бесплатный коворкинг
Нашла сеть бесплатных коворкингов по всему городу для людей до 35 лет 🤗
https://www.prostospb.team/
Вдруг кому-то пригодится!
N.B.! Внутри есть кухня с микроволновкой, но кружку, столовые приборы, сливки для кофе и печеньки нужно брать с собой 🥛
#полезное@teamcity_fairy
Послезавтра иду вот на такое замечательное мероприятие!☕️ Слёт девопсов в милой кофейне по случаю появления ветки девопс в сообществе Coffee&Code 📱 ☕️
#мероприятия@teamcity_fairy
#полезное@teamcity_fairy
Environmental drift, или сказка о том, как окружения разъехались
Жила-была команда. И было у нее три королевства: dev, stage и prod 🏰.
По документации - близнецы. Но на деле... 💔
В dev окружении: включена вся новая функциональность, ну и "тот временный фикс, чтоб быстренько тест прогнать", которому уже 4 месяца...
В prod: древнейшие зависимости и старые версии инфраструктурных компонентов, солянка временных решений "чтобы поскорее решить проблему клиента", а ещё тот невоспроизводящийся на других окружениях баг, на котором бизнес давно теряет деньги...💸
Как итог, код, отлично протестированный в dev-окружениях, падает с критичными ошибками на проде.
А расследование превращается в боль - баги невозможно воспроизвести из-за различий в окружениях.
😈Все это не умысел злых духов. Это незаметно накапливающийся хаос живущей системы...
В идеале, проблему решает Infrastructure as code, когда запрещено как-либо изменять окружение вручную, а только с помощью системы управления конфигурацией, и только сохраняя любые ее изменения в репозитории. А любые изменения кода всегда проводя через один и тот же пайплайн, никаких сборок на коленке.
Но как быть, если команда только в процессе перехода к светлому будущему 🤍, а выпускать релизы надо уже сейчас?
Вот несколько временных инструментов из магического сундучка ✨:
📗 Договориться о "принципе единой истины":
Вот лежит страничка, на которую все ориентируются. На этой страничке должны быть перечислены версии всех компонентов, значения переменных окружения, включенные фичи, различные настройки и временные решения. А также порядок шагов настройки окружения и чек-лист деплоя. Любая другая информация из других источников считается недостоверной, пока не перенесена на страничку истины.
Страничку необходимо не лениться вести сразу - окружения разъезжаются постепенно и очень незаметно.
💓 Не делайте ручных временных решений в проде без крайней нужды. На каждый такой случай заводите таск: что сделали, зачем, в какой версии и когда эта проблема будет исправлена навсегда. В релизный процесс добавьте пункт: "удалить устаревшие временные решения".
🌺 Если уже есть какая-то автоматика - старайтесь один и тот же инструмент использовать для разных окружений.
🖤 Заведите регулярную практику сравнения окружений и устранения различий. Раз в квартал, например.
💌 Если часть поддержки прода осуществляет клиент (проектная разработка), то документацию по эксплуатации новой версии составляйте на основе "странички единой истины".
✍️ Ведите реестр всех документов, связанных с настройкой окружений, и внедрите регулярную практику их проверки и синхронизации со страничкой "единой истины".
🧁Прод - это не кухня в студенческой общаге. Оставьте доступ к нему только у минимального числа самых квалифицированных людей.
🌸Если нет возможности сразу все перевести в Infrastructure as code, начинайте с маленьких шагов. Это лучше, чем отсутствие действий в этом направлении.
🌸 Существуют различные инструменты и системы для хранения информации о версиях и выяснения версий зависимых библиотек.
Поделитесь, а вам приходилось чинить инциденты из-за того, что прод жил своей тайной жизнью? С удовольствием послушаю в комментариях смешные и нелепые истории🌸
#процессы@teamcity_fairy
Как виртуалка из Англии пришла за вашим TeamCity🚌
Немного хулиганский пост выше об одном очень интересном кейсе взлома ТимСити🫡.
От Яна - одного из героев проекта интервью людей с необычной биографией. У него, кстати, тоже теперь свой канал про девопс и боль поиска работы. Возможно, этот канал сможет дать почувствовать сильному специалисту, оказавшемуся в долгом поиске работы, что он не одинок💔 🤗
Подписывайтесь!
#техническое@teamcity_fairy
#интервью@teamcity_fairy
Решила в этот раз разбавить контент чем-то весёленьким)
Тот самый сериал из детства 😍🚚
Состояние потока или нейробиология сборок🧪🌟
Быстрая обратная связь от действия - одно из условий достижения состояния потока, в котором выше продуктивность и больше удовлетворённость от работы.
Выходит, быстрые сборки делают разработчиков счастливее?💗
Да, все благодаря дофамину.
Когда говорят про скорость сборки и деплоя, обычно связывают это со скоростью релизов и тестирования фич на аудиторию, ранним обнаружением ошибок. Но есть ещё один аспект - нейробиология.
Дофамин - это нейромедиатор, который участвует в работе системы мотивации и вознаграждения мозга ❣️.
Он выделяется тогда, когда мы ожидаем вскоре достигнуть значимый для нас результат или получаем положительную обратную связь от наших действий.
Поэтому разработчики воспринимают свои успешные сборки как маленькие победы (хотя иногда и как большие, если отладка выдалась очень сложной🙈). И чем больше таких побед в течение дня, тем выше настроение, мотивация и энергия команды ☕️.
Также большую роль играет переключение контекста, когда человеку сложнее вспомнить, что именно он изменил в сборке, если он делал другую задачу, пока ждал билд. Особенно если он перед этим сделал много изменений, чтобы не запускать длинную сборку на каждое. Значит, исправление ошибки будет более медленным.
Что может помочь ускорить сборки:
✨ Кеширование зависимостей (у многих сборочных инструментов есть такая опция, но осторожнее с локальным кешом, он может менять состояние билд-агента)
✨ Грамотный dockerfile
✨ Разделять сборки на параллельные
✨ Запускать только нужные тесты и шаги у сборок (по условию, например)
✨ Позаботиться о производительности билд-агентов (мониторинг их ресурсов)
✨ Оптимизировать зависимости
✨ Следить за размером скачиваемых и выкладываемых артефактов сборок
✨ Не пересоздавать без необходимости тяжёлые сборочные и тестовые окружения
✨ Пересобирать только то, что изменилось
Работу над скоростью сборок лучше начинать с выявления самых медленных ее частей (узких мест). Некоторые билд-серверы позволяют удобно смотреть статистику скорости сборок.
Выходит, CI/CD с точки зрения нейробиологии - не просто инструмент доставки кода. Это ещё и механизм, который поддерживает быстрые циклы предсказания и обучения, под которые человеческий мозг эволюционно очень хорошо приспособлен 🤩.
P.S. А моей маленькой победой с утра было осилить этот пост 🙈🙈
Но считаю важным писать об этом. Ведь мы обслуживаем не только системы, но и людей 🤗
А вы как ускоряете свои сборки? И было ли что-то сегодня, что принесло вам удовольствие от результата?🔥
#процессы@teamcity_fairy
#психологическое@teamcity_fairy
#техническое@teamcity_fairy
#best_practices@teamcity_fairy
#выгорание@teamcity_fairy
Захотелось провести интерактив))) Расскажите в комментариях свои самые веселые или нелепые истории, связанные с работой🥳
Не обязательно прям с рабочими задачами, а можно просто, как что-то веселое творили с коллегами на работе/вне работы 🤩🌟
#забавное@teamcity_fairy
Иду завтра на такой митапчик по архитектуре☺️
https://billing.timepad.ru/event/3926287/?utm_refcode=f2fb87a776f33de1e4c3ecdc45a44fffbc02f44c
#мероприятия@teamcity_fairy
Путь в девопс с кафедры пастора: через кризис, Linux и личные границы ⛪️
Сегодня история о человеке, который прошёл путь от руководителя в протестантской церкви до DevOps-инженера.
Роман ещё с юности стал заниматься протестантским молодёжным клубом, а со временем дорос до старшего пастора Владимирско-Ивановской области.
Но IT всегда было в ❤️ нашего героя. В перерывах между организацией больших церковных мероприятий, удавалось читать книги по ит, что со временем позволило заняться фрилансом на php.
Организация конференций, выступления, управление людьми и активная публичная жизнь давали много энергии🔥.
Но, в какой-то момент, случился кризис переосмысления ценностей, и было принято решение кардинально сменить сферу деятельности на ит. К этому всегда был интерес и имелся небольшой опыт.
Этот непростой путь начался с работы сисадмином в больнице 🏥. Роман стал брать на себя много разных задач, что помогло развиваться. После, благодаря хорошей репутации с предыдущих работ, устроился сисадмином в региональную аутстаф-компанию. Там за два года вырос до старшего сисадмина, благодаря активному обучению.
✅Церковный опыт дал неожиданные преимущества: опыт управления людьми, навык делегирования, хорошие софт-скиллы, умение доносить мысли.
🔢Но были и сложности: трудно было научиться выстраивать личные границы и говорить "нет", ведь в протестантизме развита культура служения 😍.
Что решили посоветовать новичкам:
📚Нужно быть готовым к постоянному обучению (Linux, docker, virtualization, kubernetes, observability, Iac).
💝Помогают книги, курсы, ютуб, чтение документации.
🧠 Помогают Gemini, codex, Claude. Но важно использовать их для первичного решения, а докручивать решение уже по документации, тк она более актуальна.
🗞 Любознательность и любовь к новому - большое преимущество.
👩💻 Linux - фундамент.
🔧 Полезно осваивать навыки траблшутинга.
💘 Общайтесь с коллегами, спрашивайте у них помощь.
Вот так, постепенно, в жизни нашего героя проповеди сменились на инциденты и ночные алерты, а самым страшным грехом стал деплой в прод в пятницу:)
В комментариях можете задавать Роману вопросы;)
P.S. Если вы тоже хотите поучаствовать в этом проекте, можете писать мне в лс)
#интервью@teamcity_fairy
#личный_опыт@teamcity_fairy
#полезное@teamcity_fairy
Linux на чай: из официанта и рекламы в девопсы 🍰☕️
Еще одно вдохновляющее интервью состоялось у меня недавно!🤗
Герой предпочел остаться анонимным, но с энтузиазмом и любовью к своему делу преодолел путь в ит, который оказался совсем не прямым.
Также, как и в предыдущем интервью, гость этого загорелся ит еще в школе.
Главным мотиватором было желание автоматизировать задачи, которые не хочется делать самому (тут совпало с моей теорией про обучение, что это один из наиболее эффективных методов получать скиллы в ит). Также настраивал сети на компах в школе 🌐.
Получил тех образование, но после универа работал официантом☕️ и в рекламе. Чтобы облегчить себе жизнь в рекламе, приходилось искать способы автоматизации задач. Так потихоньку появлялись знания. Про девопс узнал случайно, и записался на стажировку. Был период, когда потребовалось не работать, и обучаться дома фулл тайм. Постепенно дорос до крупной компании. Опыт работы официантом и в рекламе помог научиться видеть места, которые нужно автоматизировать или оптимизировать.
Жизненные выводы и советы новичкам:
- Делать бекапы!💻
- Опыт и хорошие практики усваиваются лучше, когда наступаешь на грабли 😈
- Пробуйте, экспериментируйте. Но осторожно!🍾
- Выбирайте технологии для обучения, отталкиваясь от списка актуального на хх
- Не бойтесь просить о помощи
- Ходите на стажировки от универа (сама с них начинала, кстати, лучшее время было)
- Ходите по собесам, а не только теорию учите
- Когда читаешь книгу или доку, важно задавать себе вопросы: "а что будет, если сделать иначе" 📚
Самый интересный вывод, к которому пришли в процессе интервью, и который будет полезен студентам: активная социальная жизнь в универе прокачивает софт-скиллы и помогает лучше научиться разбираться в людях, что очень сильно пригодится в карьере =))
Вот такой интересный путь получился!
Можете в комментариях задавать главному герою вопросы, а я опубликую ответы 🤗
#интервью@teamcity_fairy
#личный_опыт@teamcity_fairy
#полезное@teamcity_fairy
Машинист метро, победивший TeamCity🚊
Не перестаю удивляться, сколько же интересных людей, оказывается, есть у меня в подписчиках!🤗
Ловите мой первый опыт в качестве интервьюера✍️
Герой этого поста - Ян, поделился с нами, как доехать в кабине машиниста электропоезда до девопс и не сойти с рельс на этом пути 🚇.
В жизни Яна было много разных сфер: медицина, спорт, строительство, аудиотехника...
Но главный маршрут оказался таким: школьный интерес к ит -> машинист электропоезда -> годы опыта в администрировании системы электронных платежей в метрополитене, которой мы все с вами пользуемся -> руководство инфраструктурными командами и девопс.
Про досуг Ян также не забывает: играет в мафию, увлекается музыкой🎵, любит путешествовать.
Интервью получилось очень объемным и интересным, вот самые полезные мысли из него:
📗 В обучении лучше всего помогло последовательное прохождение курсов по всем технологиям для девопсов (k8s, docker, python, etc) - это помогает структурировать знания.
🫂 Очень эффективным оказалось изучение технологий с коллегами, где каждый затем делился с другими изученным.
📄 Очень важно читать оригинальную документацию - там почти всегда есть советы и подсказки.
🧪 Нужно много пробовать и экспериментировать.
👨💻 Девопс сейчас из одной роли превращается в набор разных специализаций (k8s, cicd, dba, sre, noc, monitoring, platform engineering).
💖 Находить мотивацию продолжать свое дело через достижение результата, получая дофаминчик от побед.
🧠 Прежде чем что-то делать, подумать дважды.
N.B! Самое важное напутствие новичкам: делайте бекапы! Бекапов много не бывает!!!
И анекдот напоследок: "Все админы делятся на тех, кто еще не делает бэкапы, и тех, кто уже делает бекапы".
Вот такой интересный путь по тоннелям метро к пайплайнам TeamCity получился у нашего героя!🚆 Будем рады вашей поддержке! 💖
А что бы хотели узнать у Яна вы? Пишите в комментариях!🤗
#полезное@teamcity_fairy
#личный_опыт@teamcity_fairy
#интервью@teamcity_fairy
Полуюбилейный пост
У моего канала снова случилась красивая цифра - нас уже 150!🎉
И вот, что хочется сказать.
Складывать непослушные слова в смыслы. Садиться писать, даже когда вдохновения и энергии нет.
Успокаивать своих внутренних критика и редактора. Все это бывает очень непросто.
И да, зелёной кнопки "пост задеплоился успешно", как и каких-либо правил, тут тоже нет. Никогда не знаешь, что тебя ждёт. Какой пост словит обнимашек, где будет поддержка, а где - отписки.
Но, когда я представляю, что меня читает столько реальных живых людей, видя у себя в подписчиках крутых профессионалов, авторов больших классных каналов, людей, на которых мне хочется равняться и быть похожей, получая добрые слова лично, я понимаю, что все это не зря ❤️❤️❤️💖
Спасибо вам, что вы здесь 😍🐈
Никто больше не использует TeamCity: правда ли это?😱
Редко пишу тут о техническом, тк многие местные читатели из других сфер. Но недавно меня попросили рассказать об особенностях TeamCity как инструмента, о работе с большими проектами и уникальных фишках. И я подумала, что даже странно, что в канале с таким названием до сих пор нет ни одного поста на эту тему.
Ответ на вопрос из заголовка будет поджидать внимательных читателей незаметно ближе к концу поста❔
P.S. На всякий случай хочу уточнить, что название канала именно такое не из-за моего фанатизма от данной технологии, а потому, что так меня прозвали коллеги на одной из работ 🧚♀, и мне приятнее использовать ник, придуманный живыми людьми, чем выдумывать свое из головы.
Тем не менее, плюсы у TeamCity (далее ТС) действительно имеются:
🐚 Удобный UI
🔗 Работа с цепочками сборок
Одна из наиболее используемых фич - удобный, гибкий и хорошо визуализированный механизм цепочек сборок.
⛓️ Сборки по цепочке можно запускать в обе стороны (механизмы dependency и build triggers).
⛓️ Пользовательские переменные тоже можно передавать в обе стороны (dep.*, reverse.dep.*).
⛓️Можно запустить только часть цепочки, если нужно.
⛓️ В случае изменений, ТС автоматически перезапустит только изменившуюся часть цепочки.
⛓️Гарантия, что все билды в цепочке запускаются на одних и тех же ревизиях репо.
Все это позволяет создавать сложные графы зависимостей и поддерживать огромные многокомпонентные проекты, что пригождается большим компаниям.
Еще есть прикольный механизм promotion - можно взять руками старый билд, и запустить с ним новую цепочку дальнейших сборок.
Так же есть опция помечать нужные билды тегами, помогает легко находить нужный артефакт в сотнях сборок.
👨💻 Kotlin DSL
Kotlin DSL - это ооп-язык, позволяющий динамически создавать сборки на ТС и управлять сложными системами сборок. Очень мощный инструмент в плане рефакторинга и управления большим количеством кода.
💡 Позволяет использовать всю силу IDE для работы с Kotlin DSL.
✍️ ТС умеет автоматически переводить простые джобы в Kotlin DSL.
📕 Инфраструктурный код на Kotlin DSL может храниться в отдельном в репо команды инфры и быть доступен только ей - лучше контролируются безопасность и порядок.
🕵️♀️ Гибкий выбор билд-агентов
В ТС удобный и гибкий механизм выбора билд-агентов под разные сборки и требования. Например, можно выбирать агент только с необходимым количеством места на диске под сборку.
🗒 Пулы агентов
Это группы билд-агентов, объединенные по какому-то признаку. Это очень когнитивно разгружает при работе с сотнями билд-агентов.
🔐 Модель доступа
Удобная модель управления доступами с гибко настраиваемыми правами и ролями, есть интеграция с LDAP/Active Directory.
📊 Сильная визуальная аналитика
Удобная и подробная аналитика динамики скорости билдов и флаки-тестов со всевозможными графиками и детализацией.
❌ Но есть и минусы тоже:
❗️ Самый существенный - вендор лок, необходимость лицензии, гео-ограничения (кто дочитал до этого пункта, для того и откроется ответ на вопрос заголовка: к сожалению, именно по этой причине проекты с него мигрируют на другие системы, хотя на нем по-прежнему работает очень много старых проектов).
🔐 В отличии от систем, где код проекта и описание пайплайна хранятся в одном месте (e.g. Gitlab CI), здесь придется потрудиться настроить все доступы отдельно (будь то доступы к UI TeamCity или к репо с Kotlin DSL). C другой стороны, это безопаснее - централизованный контроль доступов.
🚤 ТС сложнее завести в кубере, чем некоторые другие ci/cd-системы.
🐱 Для небольших проектов лучше взять систему с более простым развертыванием и сопровождением.
Поделитесь, что бы вы еще хотели знать?)
#техническое@teamcity_fairy
Kernel panic в голове: о важности контакта с эмоциями
Очень здорово, что в последнее время начали говорить и писать о значимости навыков, связанных с мышлением, для девопсов 🧠.
Но мало кто говорит о том, что для этого навыка мало просто потренироваться решать задачи дома. На практике (особенно во время инцидента) можно столкнуться с тем, что грамотное мышление "блокируют" всякие разные психологические установки и эмоции, которые не проявлялись в безопасной среде домашней лабы. Также сюда подключаются ещё и эмоции коллег.
Поэтому очень важно не только развивать навыки мышления, но и контакт со своими чувствами, чтобы всегда четко понимать, какая эмоция сейчас берет на себя управление личностью своей и коллег, и уметь грамотно в этом разобраться и справиться.
На мой взгляд, навык распознавания и управления эмоциями - критичный, но очень недооценённый навык в нашей профессии ♥️.
А ещё это очень непросто: одновременно строить в своей голове сложные логические схемы и слушать свои чувства, тк это принципиально разные состояния и навыки. Как правило, что-то одно из этого берет верх в ущерб второму. Важно проверять, есть ли баланс 🤗.
Также может вмешиваться в мыслительный процесс доверие коллегам ❤️. Даже если есть привычка критически относиться к любой информации, доверие к ближайшим коллегам и хорошие отношения могут сыграть злую шутку. Важно всегда перепроверять, или держать в уме, что инфа неточна, если нет возможности проверки .
P.S. Когда об этом задумываешься, понимаешь, как много слоев на самом деле есть в нашей профессии, о которых мало кто догадывается. Технологии, навыки мышления и организации, эмоции... И я уверена, что впереди мне нам всем будет открываться ещё больше новых интересных слоев, и от этого даже немного захватывает дух;)
Мне это напоминает такой большой айсберг🧊, где за вершиной "эй, почини деплой" скрывается под водой огромная многослойная область знаний 🔥
Поделитесь, а у вас были ситуации, когда грамотная работа со своими и чужими эмоциями помогла достичь результата в работе?
#психологическое@teamcity_fairy
#отношения_в_команде@teamcity_fairy
🏙 Санкт-Петербург
📅 24 января 2026 (Суббота)
⏰ 11:00
😈 DEVOPS
Место: кофейня БЭНЧ
Адрес: ш. Революции, 3, корп. 2
Ссылка на календарь: Google | Apple
Запускаем направление DevOps в Coffee&Code совместно с DeusOps! 🎉
Встретимся в нашей собственной кофейне для первого знакомства, обсуждения новостей и ненапряжного начала дня с хорошей компанией.
Ну и конечно попьём кофе ☕️
Канал Coffee&Code - @ChatCoffeeCode
Канал DeusOps - @deusops
Канал кофейни БЭНЧ - @benchplace
Локальный чат города
Организатор встречи
- SlugPlay
Пишите по любым вопросам.
Распознавание эмоций и немного крови
Поскольку мой канал не совсем уж серьезный, и, как я предполагаю, временами в него заглядывают для развлечения, решила разбавить контент веселой (хотя и немного страшной) офисной историей.
Дело было в те древние времена, когда люди ещё ходили в офисы. Одним из проектов компании, в которой я тогда работала, было приложение по распознаванию эмоций ❤️. Обучающую базу для этого приложения собирали на сотрудниках.
Меня выбрали одним из участников этой базы.
Сначала все шло хорошо. Мне показывали различные видео и картинки, вызывающие разные эмоции. От котиков👀 до скорпионов 🦂. Специальная камера фиксировала разные выражения лица, чтобы потом видео можно было разметить по эмоциям и отправить в базу.
В конце мне объявляют, что остался последний, завершающий этап эксперимента. Нужно измерить уровень адреналина в крови ("не волнуйся, мы специально обучены"). И ставят на стол набор с иголкой, ватой, бинтом, пробиркой, перчатками и жгутом... 🩸
Я растерялась, и говорю: "ну раз для науки надо, так надо".
И...
Пауза. Ничего не происходит. Все смотрят на меня. Я просто сижу.
********
Несколько минут спустя, экспериментатор не выдерживает, и говорит: "Это была попытка тебя напугать, чтобы записать эмоцию страха, но ты слишком невозмутимая!!!".
Дали мне конфетку 🍭, и отпустили с миром))))
Поделитесь, а у вас были прикольные истории в офисах?
#личный_опыт@teamcity_fairy
#забавное@teamcity_fairy
Роадмап для девопса
В продолжение предыдущего вопроса о роадмапе. Тема очень большая, потому вынесла ответ в отдельный пост.
Целеполагание
Как писала в посте про обучение, считаю наиболее эффективным обучение, отталкивающееся от конкретной задачи. По этой причине будет неправильно просто порекомендовать конкретный роадмап/курс/список книг.
Поэтому первым делом необходимо сформулировать для себя задачу. Зачем нужен роадмап? Задача может быть научиться хорошо проходить собеседования, или получить конкретную роль в команде мечты, или работать в той области, которая интересна, или повысить грейд, etc. У каждого задача своя, поэтому и общие рекомендации не будут работать. Также полезным может оказаться определиться с типом задач, которыми хочется заниматься на работе.
Отталкиваясь от этого, необходимо продумать свою стратегию 📝. Например, необходимые шаги для подготовки к собеседованиям будут сильно отличаться от задач, связанных с повышением своей эффективности для бизнеса.
Что нужно бизнесу
Человека нанимают на работу не для того, чтобы он знал конкретные технологии, а для того, чтобы он закрывал какие-то боли бизнеса💔.
По опыту, часто за техническим описанием вакансии скрывается нужда в человеке, умеющем выстраивать процессы. Хотят не чтобы человек "настроил пайплайн", "запилил автодеплой", а чтобы человек выстроил удобный и эффективный процесс работы с ними. И на этом стыке часто возникает проблема: тот, кто ставит задачу, хочет просто решить свою проблему, а наталкивается на кучу вопросов с непонятными терминами со стороны сильного технически спеца. А специалист, в свою очередь, не может понять, что ему делать, или делает не то. И отсюда вытекает огромное поле для изучения: построение процессов delivery/cicd/release, метрики процессов (dora, mttr, time-to-market, etc)📊, принятие решений в условиях неопределенности, управление рисками, cost management, смотреть не в задачу, а в исходную проблему и тп.
Навыки мышления
Я бы выделила два самых важных навыка для девопса: системное мышление и траблшутинг.
Важно не знание конкретной технологии, а то, как использовать подобные технологии для решения задач. Поэтому учить нужно не технологии - учиться нужно решать задачи:)
Ну и довольно большую часть рабочего времени девопс проводит, расследуя. Поэтому важно уделять навыку траблшутинга внимание 🤔.
Developer experience
Эту область знаний хотелось выделить отдельно, потому что часто этому уделяют мало времени и внимания. Но важно помнить, что мы прежде всего нужны для обеспечения процесса разработки, а это интеллектуальная деятельность. Значит, ее эффективность сильно зависит от внутреннего состояния работников. Поэтому давайте стараться делать жизнь разработчиков приятнее. Хотя бы держать это в уме, и реализовывать при возможности 💕.
Как стать умнее ии
А ещё я думаю, что технологии знает иишка, и корп базу знаний, код ему скормить тоже можно. Но я не очень себе представляю, как он сможет знать контекст, хранящийся в головах у коллег, и информацию, которую можно получить, только зайдя на какой-то сервер, и посмотрев, что там происходит, как и с кем система на этом сервере взаимодействует. Особенно если таких серверов, виртуалок и прочего тысячи. Поэтому, я думаю, сейчас очень важен навык изучения сложной корп инфры и ее взаимосвязей. Интересно, начнут ли сотрудники создавать "теневые корп базы знаний", с закрытым доступом для ии, чтобы их нельзя было заменить? 💭
Технологии
Для получения актуального списка технологий рынка имеет смысл периодически смотреть списки требований вакансий, и выписывать самое популярное.
Для изучения этого полезно найти что-то общее в уже имеющихся технологиях, чтобы легче изучать следующие (например, чтобы изучать новые системы CI, нужно понимать принципы построения пайплайнов), а также изучать фундаментальные технологии, на которые наслаиваются новые (например, чтобы лучше понимать ансибл-роли, важно знать линукс, а чтобы осваивать кубер, хорошо бы понимать, как работает докер).
На этом этапе, когда цели определены, проведены аналитика по рынку и...
Продолжение в комментах
Друзья! Всех поздравляю с наступающим!🎄🏠
Во многих тг-каналах сейчас принято подводить итоги года.
Я, в свою очередь, предлагаю чуть изменить эту традицию и вспомнить не о своих результатах в прошедшем году, а о том, что принесло яркие эмоции✨, что самое красивое увидели🤩, что удивило🦋, что вдохновило🌹, что открыли и узнали для себя нового🌎, кому получилось помочь🫂, кого порадовать💕, с кем стали лучше отношения 🐾.
Делитесь в комментариях!