Рады сообщить, что 9 февраля состоится наш новый DOMашний митап.
Мы решили опять устроить панельную дискуссию, на которой соберемся нашей командой и расскажем, как попали в IT, дадим советы, как расти на начальных этапах IT специалисту, и обсудим еще много интересных тем.

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

Детально о спикерах мы расскажем в следующих постах, хотя вы и так с ними неплохо знакомы 😉

🗓 Дата и время: 9 февраля, 17:00 (UTC +3)
А пока регистрируйтесь по ссылке и следите за нашими новостями.
https://community-z.com/events/devopsminsk-meetup-11

Ждем всех на нашем митапе 🤘🏻

Пришло время знакомить вас со спикерами нашей панельной дискуссии.

Первый на очереди - Максим Белицкий, Systems Engineering Team Leader в компании Epam System.

Максим 10 лет работал системным администратором/эникейщиком пока не узнал, что существует DevOps. За 4 года в Epam он прошел путь от студента до Systems Engineering Team Leader 🤘🏻

Несколько фактов о Максиме:

▪️ Знает, что общего между карандашом и кассетой, отверткой и utp кабелем.
▪️ Устанавливал Windows начиная с 95 и до Windows 10

На митапе Макс поделится своим опытом и расскажет, как собирать левелы в EPAM.

Будьте внимательны, мы сместили дату нашей панельной дискуссии на 9 февраля!

Регистрация на митап по ссылке: https://community-z.com/events/devopsminsk-meetup-11

Продолжаем знакомить вас со спикерами нашей следующей панельной дискуссии.

Сегодня расскажем о Михаиле Сагаловиче.

Михаил - DevOps Practice Lead в компании ISsoft.

После 10 летней работы .Net разработчиком и архитектором, кривая карьеры вывела его в менеджмент 😮 Делал (плохо) DevOps еще до того как узнал, что это называется DevOps. Теперь старается не мешать другим делать DevOps хорошо.

Несколько фактов о Михаиле:
▪️ Разрабатывал систему имитации горения пожаров для МЧС на C++
▪️ Сидел на воркшопе у Дино Эспозито и фиксил баги в публичных библиотеках вместо участия в воркшопе.

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

Регистрируйтесь на митап по ссылке: https://community-z.com/events/devopsminsk-meetup-11

​​"А какой уровень DevOps, как процесса разработки, у меня на проекте?"

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

За основу выпуска взяли довольно старую статью DevOps Maturity Model и решили разобрать, насколько она актуально в 2022-ом году. Таблицу из статьи перенесли в google spreadsheets , чтобы вы самостоятельно могли оценить свой уровень.

Также обсудили, как один человек с довольно популярной npm библиотекой смог сломать пол-интернета.

Саша раскрыл тайну практики DDD (Davai Davai Deploy), как его внедрять на проекте.

Максим рассказал свои лучшие практики: как надо заходить на прод и прямо на живую менять конфиги и деплоить туда код (всё в рамках DDD подхода)

А какой у вас на проекте уровень DevOps, пишите в комментариях 👇🏻

Следующий спикер нашей панельной дискуссии, о котором мы расскажем – это Ярослав Будянский.

Бывших PHP разработчиков не бывает – бывают просто не практикующие или не признающиеся, что практикуют. Попробовал PHP Ярослав еще в старших классах и первый раз получил деньги за написаный код в 2004, что считает стартом своей айтишной карьеры.

Ярослава всегда интересовало, что происходит с написанным кодом, поэтому практиковать DevOps начал еще до того, как это направление получило такое название.

Факты о Ярославе:

🔹 С детства хотел себе футбольный клуб, и когда подвернулась возможность им завладеть, он ею воспользовался ⚽️
🔹 Опытным путем выяснено – способен прожить без электричества и интернета не менее 26 часов.

На панельной дискуссии Ярослав расскажет, как инженеру убить в себе менеджера и еще много интересного.

Поэтому не пропустите наш крутой митап и не забудьте зарегистрироваться на него по ссылке:

https://community-z.com/events/devopsminsk-meetup-11

Сегодня расскажем вам о Викторе Ведмиче - Senior Developer Advocate в Amazon Web Services.

Виктор начинал свою карьеру разработчиком на Delphi, но кризис 2009 года заставил его переключиться на поддержку и администрирование. Уже 2011 он начал внедрял практики DevOps на проекте в EPAM, запуская CI/CD на CCNET. А через некоторое время он организовывал zero-downtime deployment. Виктор применял практики DevOps еще до того, как это стало модно и популярно 😜 Он долгое время работал инженером-архитектором на проектах, и всегда делился знаниями через комьюнити и подкаст 👐🏻

Несколько фактов о Викторе:
▪️ Постоянно попадает на приключения при сертификации.
▪️ Проходит игры только на харде.
▪️ Подмял под себя бизнес в общаге.

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

Регистрираций по ссылке https://community-z.com/events/devopsminsk-meetup-11

Наш 5й спикер - Дмитрий Курьянович, Head of Maintenance в Wargaming.

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

Несколько лет Дмитрий работал системным администратором портала tut.by. Потом 4 года – над «танками» в Wargaming, а затем свернул в менеджмент. Теперь он смотрит на IT “сверху”, в хорошем смысле слова 😊

Несколько фактов о Дмитрие:

🔹 Когда пришел на первую работу в IT, первым делом поднял сервер counter strike.
🔹 Всегда считал, что дежурство по продакшену – это не причина сидеть дома, поэтому работать приходилось из самых разных мест.

На митапе Дмитрий расскажет про то, как менеджеру убить в себе инженера, и нужно ли менять работодателя 😉

Не забудьте зарегистрироваться 👉🏻
https://community-z.com/events/devopsminsk-meetup-11

Напоминаем вам, что завтра в 17:00 (UTC +3) пройдет наш домашний митап.

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

Ну что, давайте начнем?

Наш стрим начнется ровно через час - включайте напоминание 😉

https://youtu.be/f5GtdJ4getw

Мы начинаем 🔥 Скорее переходите по ссылке https://www.youtube.com/watch?v=f5GtdJ4getw

Всем большое спасибо за участие в нашем митапе. Мы стараемся делать для Вас классные ивенты 😉
Вы можете помочь нам стать еще лучше, заполнив эту форму https://forms.gle/yedvnFNxQXHZsy9j8

​​А говорят, что DevOps-ы уже не в тренде, и все хотят теперь только SRE? Так а в чём же разница между этими двумя специалистами? Какая матрица знаний для них?

Еще в далеком 2009-м, когда провели только первую конференцию DevOps Days, появился термин DevOps. В тоже время в Google начало формироваться SRE: всё началось со статей и по итогу статьи сформировались в большую книгу с названием Site Reliability Engineering.
И вот в 2022 году, всё больше и больше вакансий появляется для SRE специалистов. Так это всё такие же DevOps-ы, только с фокусом на поддержку и мониторинг? Или это новые единороги, которых видели, только с большим кошельком?

Мы вместе с Максом и Сашей сделали DKT edition матрицы знаний: кому какие знания более важны и нужны, и в целом какими знаниями должны обладать SRE и DevOps специалисты.

А если нужна картинка, которая в результате получилась, пишите — поделимся.

​​Год назад мы приступили к готовке Continuous Integration и Continuous Delivery. Но блюдо оказалось настолько сложным, что его приготовление заняло целый год. Но если DKT обещает в мае, мы свои обещания выполняем. Тулы приходят и уходят, а концепты остаются, в нашем детальном разборе CI/CD вы найдете принципы и подходы, которые сможете применить к любому вашему любимому CI тулу. Большого слона в виде CI/CD blueprint-а мы приготовили по кусочкам, все тайм коды есть в описании к видео.

Мир технологий постоянно меняется, появляется новое, забывается старое, эволюционируют профессии. Хочется такие события обсуждать и делать для себя полезные выводы. Именно поэтому мы решили ввести рубрику #DOM_review, в рамках которой мы будем рассматривать одну или несколько животрепещущих тем, давать краткую оценку ситуации и обмениваться мнениями с вами.