Обучение на курсах мы практически не используем. Чтобы хорошо усвоить материал курса, на него нужно прийти уже с практически знаниями в изучаемой области. С другой стороны, человеку, погрузившемуся в изучаемую область курсы мало полезны, т.к. в большинстве их уровень достаточно базовый и при этом сильно обобщённый, отличающийся от того что действительно есть в компании.
У нас есть junior позиции, но их мало. Мы сделали значительный акцент на автоматизацию и закрыли большую часть задач для которых требовался такой уровень. Мы так же скорректировали подход к подбору на junior позиции, выбирая людей с хорошо выраженными парадигмой Win – Win, развитием и результативностью. Поиск таких сотрудников — это отдельный вопрос.
Мы шли по пути набора на junior позиции и выращивания из них специалистов, но столкнулись с проблемами:
Значительные усилия и время тратятся специалистами уровня senior для обучения, тем самым отвлекая их от задач бизнеса;
В среднем до уровня middle сотрудник вырастает за 1,5-2 года;
После того как сотрудник понимает, что его уровень близок к middle, он старается перейти на более интересные ему задачи. Теперь ставшие для него рутинными задачи выполняются с нежеланием. При том что 70% задач это как раз такие.
Через некоторое время сотрудника достигшего уровня middle хантят другие компании. Т.к. у нас современный стек, то такие специалисты сейчас популярны. Лояльность к компании не имела решающего фактора, для того чтобы остаться.
И да, у нас уютный офис, хорошая команда профессионалов и отлаженные процессы, как и в большинстве современных ИТ компаний.
Да, сразу начали использовать. Нам было проще, т.к. автоматизацию windows инфраструктуры делали SRE с сильным linux бэкграундом, давно использовавшие ansible и знакомые с powershell.
Осуществили, такой же переход, с DSC на Ansible. Переход оправдал себя полностью. Преимущества использования Ansible, которых мы не смогли достичь с DSC:
* В Ansible порог входа ниже и он гибок в реализации различных сценариев, которые в DSC нужно было решать через powershell. Как результат, в разработку инфраструктурного кода включились другие подразделения (Dev, ИБ) и это снизило нагрузку на SRE.
* Мы смогли реализовать удобное тестирование инфраструктурного кода используя molecule и сделать его частью нашего CI. Запускаем тесты в подготовленном docker образе с vagrant и другими нужными нам утилитами. Это так же снизило нагрузку на SRE, т.к. ушло полу ручное тестирование кода DSC при Merge Requests. Тесты для DSC ранее были написаны используя сам DSC и Pester, но их реализация сложнее.
* Deploy с Ansible предсказуемый, в особенности если он становится частью CI/CD pipelines.
Есть ряд задач которые DSC решает лучше, мы используем его в таких случаях, т.к. Ansible позволяет использовать DSC модули.
С WinRM у нас проблем не было, по тестам он работал даже быстрее и стабильнее на каналах с высокой задержкой.
Смотря в каком контексте использовать, вот ссылка с описанием для Linux. Мы в компании использовали DSC несколько лет, сейчас практически всё переписали на ansible, те моменты в которых DSC показал себя хорошо задействовали через ansible модуль. Получилась такая вот комбинированная CM.
Обучение на курсах мы практически не используем. Чтобы хорошо усвоить материал курса, на него нужно прийти уже с практически знаниями в изучаемой области. С другой стороны, человеку, погрузившемуся в изучаемую область курсы мало полезны, т.к. в большинстве их уровень достаточно базовый и при этом сильно обобщённый, отличающийся от того что действительно есть в компании.
У нас есть junior позиции, но их мало. Мы сделали значительный акцент на автоматизацию и закрыли большую часть задач для которых требовался такой уровень. Мы так же скорректировали подход к подбору на junior позиции, выбирая людей с хорошо выраженными парадигмой Win – Win, развитием и результативностью. Поиск таких сотрудников — это отдельный вопрос.
Согласен, но ресурсы каждого тимлида и в целом у небольших компаний ограничены, а амбиции у сотрудника на старте обычно завышены.
Мы шли по пути набора на junior позиции и выращивания из них специалистов, но столкнулись с проблемами:
Значительные усилия и время тратятся специалистами уровня senior для обучения, тем самым отвлекая их от задач бизнеса;
В среднем до уровня middle сотрудник вырастает за 1,5-2 года;
После того как сотрудник понимает, что его уровень близок к middle, он старается перейти на более интересные ему задачи. Теперь ставшие для него рутинными задачи выполняются с нежеланием. При том что 70% задач это как раз такие.
Через некоторое время сотрудника достигшего уровня middle хантят другие компании. Т.к. у нас современный стек, то такие специалисты сейчас популярны. Лояльность к компании не имела решающего фактора, для того чтобы остаться.
И да, у нас уютный офис, хорошая команда профессионалов и отлаженные процессы, как и в большинстве современных ИТ компаний.
* В Ansible порог входа ниже и он гибок в реализации различных сценариев, которые в DSC нужно было решать через powershell. Как результат, в разработку инфраструктурного кода включились другие подразделения (Dev, ИБ) и это снизило нагрузку на SRE.
* Мы смогли реализовать удобное тестирование инфраструктурного кода используя molecule и сделать его частью нашего CI. Запускаем тесты в подготовленном docker образе с vagrant и другими нужными нам утилитами. Это так же снизило нагрузку на SRE, т.к. ушло полу ручное тестирование кода DSC при Merge Requests. Тесты для DSC ранее были написаны используя сам DSC и Pester, но их реализация сложнее.
* Deploy с Ansible предсказуемый, в особенности если он становится частью CI/CD pipelines.
Есть ряд задач которые DSC решает лучше, мы используем его в таких случаях, т.к. Ansible позволяет использовать DSC модули.
С WinRM у нас проблем не было, по тестам он работал даже быстрее и стабильнее на каналах с высокой задержкой.