Комментарии 12
Классная, лёгкая и понятная статья. Респект за подходы на интервью!
Поясните пожалуйста место БД / SQL / NoSQL в DevOps практиках.
В 90% случаев на проектах будет SQL или NoSQL движок. Например, в CI/CD может быть шаг с изменением DB или «миграции» данных, это уже достаточно распространенная практика, и существуют специальные фреймворки. Но в большинстве случаев, по базам данных придется знать на базовом уровне, что то из пунктов (не обязательно все):
— Понимание работы репликации
— Мониторинг
— Бэкапы
— Настройка доступа
— обслуживание DB: индексы, дефрагментация, апдейт статистики ect
может звучать страшновато, но для различных движков SQL/NoSQL процессы очень похожи и доступны для изучения, главное не пугаться.
— Понимание работы репликации
— Мониторинг
— Бэкапы
— Настройка доступа
— обслуживание DB: индексы, дефрагментация, апдейт статистики ect
может звучать страшновато, но для различных движков SQL/NoSQL процессы очень похожи и доступны для изучения, главное не пугаться.
Пойду покажу статью своему сисадмину, чтобы он начал тихо плакать
Сисадминов надо беречь, никто не знает чем они занимаются, а ребята огромную работу проделывают, господин Лимончелли про их работу, аж два тома написал, по тысяче страниц каждый!
Спасибо за статью. У меня опыт только «тестовый», но очень интересно некоторые инструменты и технологии выучить, а также — применять.
Интересно мнение автора по поводу необходимости понимания процессов под капотом для уровня advanced и expert. Очень часто приходится общаться с кандидатами, которые имеют годы реальной работы с каким-то инструментом, но при этом совершенно не понимают принципов на которых инструмент построен - для них все что ниже это некая «магия». Мне кажется такое возможно когда есть большая команда и человек годами занимается некой работой по-шаблону.
О да, проклятие «вечного джуна/мидла» существует, например когда на проекте «сапортишь» чужой код, и не пишешь свой. Так же и с процессами, проект может не дать видимости. Про «необходимость понимания процессов под капотом для уровня advanced и expert» уточните пожалуйста, не очень понял вопрос…
Ну например человек работал с Kubernetes, писал манифесты, helmcharts, настраивал HPA и ingress… при этом он понятия не имеет, как устроен куб, как осуществляется сетевое взаимодействие на ноде, как между нодами, как работают лимиты на уровне ядра и т.п.
Или если Kubernetes видел только в клаудах и понятия не имеет, что там на мастернодах происходит, кнопочку нажал — кластер появился.
Какой уровень по вашей квалификации у таких специалистов?
Или если Kubernetes видел только в клаудах и понятия не имеет, что там на мастернодах происходит, кнопочку нажал — кластер появился.
Какой уровень по вашей квалификации у таких специалистов?
Так прямо не ответить, что это за квалификация, мало контекста. Если человек запустил EKS, написал сначала кучу манифестов а потом «завернул» сложное приложение в HELM и все работает то это позитивный сценарий. Да он не знает компоненты k8s, но это и хорошо, например если на проекте куча инструментов то он спасет себя от перегрузки информацией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собеседование в DevOps Engineering, как оценить свой опыт и сколько нужно знать?