⭐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

итерации и фазы

вроде уже говорилось, но повторю.

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

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

разделите проект на стадии или фазы. не пресловутое "давайте слона есть по кусочкам" (кто вообще ест слонов?!), но именно "я сделаю МВП или ПоК и потом уже пойму куда ведет дальше нас"

если твой ПоК занимает больше спринта времени — упрощай.

если твой МВП сразу работает как надо — выкатывай и отдавай в эксплуатацию.

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

но делай, делай и получай результат, улучшай, делай еще лучше, но не парься, если не получилось сразу идеально и целиком.

привет big tech night

привет, devoops

https://events.yandex.ru/events/bigtechnight/records ищите тут материалы с BTN!

привет, скейл

это фото того стоило, граждане))
сыч теперь независимый эксперт и еще и звезда стенд апа!

Кто нибудь расскажет мне как в бигтехах уживаются следующие взаимоисключающие параграфы?

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

2. Все работяги как на подбор. Дохера вумные, за спиною книжки и небритые подмышки. Процесс найма, как будто там рокетсаенс на каждом шагу.

Почему сильные кадры делают слабо?