еще разок про перф ревью

вообще не люблю возведение в культ, даже если это культ девопс))

но сейчас у многих начнется летнее ревью и вот что я точно вижу: все извращено не в ту сторону)

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

однако, правильнее давать обратную связь как можно скорее и четче, чтобы не было проблем с "ой я уже и ситуацию не помню, но записал себе что ты был не прав" или похвалы из разряда "да все норм, даже не вспомню что не так"

так и вижу — бегают все перед самым перф ревью и закрывают задачи строго из листа "Цели на квартал", при том те, которые оценят люди, дающие обратную связь по 360.

ну да, да) планироваться и идти по плану — дело неблагодарное, лучше в огне латать дыры (потому что на техдолг не хватило капасити) и ублажать хотелки высоких господ.

про себя могу сказать — мне пофиг, какую оценку я получу на перф ревью, ведь моя оценка — это моя работа — вот на неё мне не пофиг, и обратную связь мне дадут сразу)

я тут в ПК одной конференции участвую, давайте подавайтесь с докладами и приходите послушать тоже

мотивация

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

если денег недостаточно — волк смотрит в лес.

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

плюшки и премии — это всегда риск, поэтому я давно не смотрю на "совокупный доход", а делаю комфортный оклад.

конечно, мне, как руководителю, важно иметь стимул и достигать показателей. но вот в чем прикол — премии это демотивация.

очень редко видел, чтобы премия действительно была премией, а не морковкой, за которой бежит человек.

премия должна быть чем-то неожиданным и приятным. а не рычагом воздействия.

перф ревью (даааа, опяяять) — это инструмент оценить производительность и улучшить её, а не выбить премию (или, что чаще бывает — срезать)

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

если OKR ставить конечным исполнителям — то мы тоже получим демотивацию, ровно по тем же признакам.

а если человек работает плохо — то его надо мотивировать, а не демотивировать. либо расставаться.

оказывается, запись доклада-то уже есть)

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

второе, по теме тестовых стендов в ламоде будут еще доклады на big tech night и, надеюсь, они будут более объемные и интересные + с июзминкой)

погнале!

ЗЫ: Илья, ты крутой, реально такое решение изобрести и внедрить за такие сроки — сила! Артём тоже сила!

смотрите что! точнее, кто! сама Таня! я там буду, и ты приходи!

⭐MEETUP⭐
Проконсультируй меня если сможешь 🤖👨‍💻

📅8 июля в 18:00
📍Аудитория 1405, Кронверкский 49
👉 Регистрация открыта до 15:00 7 июля

Спикеры
Откроем завесу тайны позже🤫

Мероприятие проходит при поддержке факультета ПИН

Обсудим:
- Когда помочь коллеге, а когда отказать
- Должен ли DevOps-инженер заниматься рутиной
- Как не утонуть в ворохе просьб и вопросов
Также вас ждёт нетворкинг, пицца🍕 и единомышленники

Все вопросы по мероприятию можно задать в комментариях➡️: https://t.me/inview_club
А общение происходит в чате клуба➡️: https://t.me/+nSELCyIX8ltlNjU6

Не забудь зарегистрироваться на митап
Ссылка на регистрацию: https://forms.gle/P8VCD4m1dgotjvUE9
Ждём всех💫

был там

Практики, подходы, процессы, инструменты

На митапе в ИТМО мы с ребятами затронули важную штуку: что такое практики, подходы, процессы и как они разделены (или объединены) в разных компаниях.

А сегодня оказалось что даже у нас не все понимают разницу.

Ну что ж. Подход — это культура, может быть даже методология, на основе которой мы действуем. Например, девопс — это подход. Весь, целиком. Считайте как философия, религия, способ работы, жизни. Туда же можно отнести SRE.

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

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

Инструмент или технология — это уже конкретный туллинг. Например, гитлаб, с его особенностями, эластик с его сложностью, кубер как технология.

Важно помнить, что Люди - Процессы - Технологии — именно в таком порядке, сначала делаем хорошо людям, потом — ставим процессы, а потом уже копаем в технологии.

спасибо, ЖПТ, заменил ссылки битые на реальные))

Подходы:
- DevOps — культура объединения Dev и Ops
[DevOps Explained by Atlassian](https://www.atlassian.com/devops)
- Agile — гибкая итеративная разработка
[Agile Manifesto](https://agilemanifesto.org/)
- SRE — надежность через программирование
[Google SRE Book Summary](https://landing.google.com/sre/book.html)
- DevSecOps — безопасность в разработке
[DevSecOps Guide by Microsoft](https://docs.microsoft.com/en-us/security/devsecops/)
- Platform Engineering — внутренние платформы для разработчиков
[Thoughtworks Platform Engineering](https://www.thoughtworks.com/radar/techniques/platform-engineering)

---

Практики:
- Continuous Integration (CI) — частое слияние и автоматические сборки
[CI Best Practices by Martin Fowler](https://martinfowler.com/articles/continuousIntegration.html)
- Continuous Delivery (CD) — автоматический деплой
[Continuous Delivery Book by Jez Humble](https://continuousdelivery.com/)
- Infrastructure as Code (IaC) — инфраструктура как код
[Terraform Getting Started](https://learn.hashicorp.com/terraform)
- Автоматизированное тестирование
[Testing Pyramid by Mike Cohn](https://martinfowler.com/articles/practical-test-pyramid.html)
- Мониторинг и алерты
[Monitoring Best Practices by Honeycomb](https://www.honeycomb.io/blog/best-practices-for-observability)

---

Процессы:
- CI/CD pipeline — последовательность шагов от кода до релиза
[Building a CI/CD Pipeline by CircleCI](https://circleci.com/blog/what-is-ci-cd/)
- Incident Management — управление инцидентами
[Incident Management 101 by PagerDuty](https://www.pagerduty.com/incident-response/incident-management/)
- Change Management — управление изменениями
[ITIL Change Management Overview](https://www.axelos.com/best-practice-solutions/itil/what-is-itil)
- Release Management — координация релизов
[Release Management Guide by Atlassian](https://www.atlassian.com/continuous-delivery/release-management)
- Knowledge Sharing & Communities — обмен знаниями
[Creating Knowledge Sharing Culture](https://www.tinypulse.com/blog/creating-a-knowledge-sharing-culture-in-the-workplace)

---

Технологии (инструменты):
- Jenkins / GitLab CI / AWS CodePipeline — CI/CD системы
[Jenkins Documentation](https://www.jenkins.io/doc/), [GitLab CI Docs](https://docs.gitlab.com/ee/ci/), [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
- Kubernetes / Docker — контейнеризация и оркестрация
[Kubernetes Official](https://kubernetes.io/docs/home/), [Docker Docs](https://docs.docker.com/)
- Terraform / CloudFormation — Infrastructure as Code
[Terraform Documentation](https://www.terraform.io/docs), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
- Prometheus / Grafana / Datadog — мониторинг и визуализация
[Prometheus Docs](https://prometheus.io/docs/introduction/overview/), [Grafana Labs](https://grafana.com/docs/grafana/latest/), [Datadog Monitoring](https://www.datadoghq.com/monitoring/)
- Vault / AWS Secrets Manager — управление секретами
[HashiCorp Vault](https://www.vaultproject.io/docs/), [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)

мое лицо когда (всегда)

быть лучше и баланс

сколько ни рефлексировал на тему амбиций и достигаторства — всё одно: это лишнее

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

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

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

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

лучшие практики — не залог успеха. и в этом тоже нужен баланс.

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

собеседования

одной из любимых частей моей работы всегда были собеседования (нет, я не про хопанье, гусары!)

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

при этом я проводил и классические технички, и топ-грейдинги и комбо для лидов.

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

а ещё, наверное, я повидал столько разных инженеров и менеджеров, что могу, при должном усилии, как-то их классифицировать (но пока не хочу)

кстати, зачастую собеседование воспринимается как «мы проверяем кандидата», а ведь это игра в обе калитки и собеседуемый может (и должен!) задавать вопросы. всегда удивляет (и обычно ставит крест) собеседник, говорящий «у меня нет вопросов»

небось соскучились по докладам от меня?

как и говорил раньше — я в ПК bigtechnight, отбирал в трек ламоды самые крутые доклады от крутых спикеров. пять крутых докладов от шести (!!) спикеров ждут вас (и нас) в офисе ламоды и (потом) в записи.

но мало того, один из докладов — конечно от меня. однако, подождите, там будет два спикера — со мной будет Юля (а у Юли нефиговый такой бэкграунд в бигтехах) и мы поговорим о том как You Build It You Run It существует и как мы в этом всём варимся.

мало? тогда давайте еще анонс — я на хард-треке ламоды на bigtechnight еще и ведущий!

продано? тогда го! Lamoda Tech