Вчера не состоялся стрим из-за нестабильной воздушной обстановки в регионе.

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

Сейчас будет что-то на сложном.

Никто не знает хороший маниуал по построении архитектурных схем по нотациям с4?

Сейчас погружаюсь в архитектуру более глубоко

Прячем секреты приложения. Как Kubernetes помогает защитить ваши данные?

Разберём на бесплатном вебинаре в учебном центре Слёрм!

Виталий Лихачев, SRE в нидерландском тревелтехе и Максим Киселев, руководитель разработки Deckhouse Stronghold встретятся, чтобы обсудить:

🔵 Как правильно спроектировать приложение, чтобы оно безопасно получало конфигурацию при работе в Kubernetes
🔵Как избежать утечек секретов
🔵Почему хранить секреты в Vault безопаснее, чем где-то еще
🔵Что делать, если часть конфигурации — это конфиденциальная информация.

📆 Когда: 27 августа в 19:00 мск

Разработчики, подключайтесь. Пообщаемся, поспорим и разберём реальные кейсы🔥

👉 Занять место на вебинаре и получить напоминание о встрече — в боте.

#реклама
О рекламодателе
erid: 2W5zFGoWioA

🎉 Викторина завершена! Сколько правильных у тебя получилось?

🔹 9-10 — Ты — DevOps-гуру, настоящая звезда индустрии!
🔹 6-8 — Очень хороший уровень, продолжай в том же духе.
🔹 3-5 — Отличный старт, углубляй знания и практика сделает мастера.
🔹 0-2 — Время освежить базу, но это только начало пути!

Пиши результат в комментариях и пиши, какую тему хочешь проверить в следующий раз: Kubernetes, Docker, Terraform или Monitoring?

Эффективный Онбординг.

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

Подписчики часто спрашивают: как эффективно пройти онбординг?

Я считаю, что нужно плотно работать с документацией.

В процессе онбординга тебе поставят задачи, которые направлены на погружение в продукт или процессы компании.
Что делать если не поставили? Ставить самому.

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

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

Что делать если нет документации? Пишешь с нуля.

Каждая твоя задача по итогу может содержать артефакты:
- коммит в git репозиторий
- ссылку на переработанную или новую документацию
- новая задача

Пример. Нужно разобраться с деплоем сервиса.

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

И так далее.