Комментарии 25
Спасибо, мы свяжемся с Вами и сообщим результат
Рискую огрести минусов, но все же выскажу мнение, что задавать вопросы о девопс, пайплайнах и т.п. на интервью не имеет смысла. Всему этому сотрудник может очень быстро научиться. Когда я впервые устроился в компанию, где DevOps практиковался повсеместно, я умел хорошо программировать но о пайплайнах знал чуть более чем ничего — просто так уж сложилось, что на предыдущих местах работы вопросы деплоя, мониторинга и т.д. решались отдельными людьми. Ничего, я быстро разобрался. И десятки других кандидатов приходили, не зная этого, и тоже разбирались.
Ну вот скажет Вам кандидат, что он не знает, как это все устроено. Много ли полезной информации Вы извлечете из его ответа? На мой взгляд, примерно, около нуля.
Имхо надо говорить о прошлом опыте, программировании, лидершипе и концепциях (вот тут и можно оценить умение рассуждать). А девопс, если знает — превосходно, нет — ничего страшного.
Плюсанул бы с размаху, но карма не позволяет.
Таки да, я полностью согласен. Подобным вещам любой человек имеющий что-то хотя бы смутно напоминающее мозг внутри черепной коробки научится довольно быстро (было бы желание). Зачастую при построении конвеера "от кода до прода" больше проблем возникает при выборе инструментов чем при реализации.
проблема не в том кто будет это делать — а в поддержании рабочей структуры
вот я сисадмин — я вижу инфраструктуру в целом, настраиваю ее, договариваюсь с людьми о взаимодействии между организациями, а программисты в основном закрыты в своем мире ограниченном адресным пространством(как вам такое слышать? или если я к примеру скажу что как программист вы не очень — потому что не сможете спроектировать реалтайм менеджер сообщений с горизонтальным масштабированием)
я минус не поставлю, но осуждаю=) каждому своя работа, каждому свои задачи и ответственность, но зачастую приходится не только слышать дискриминацию подобного плана, но и видеть дискриминацию в зарплатах — спрашивается за что?
Не совсем. Вы немного спекулируете понятиями. :) Ну т.е. конечно, да, можно и в программировании на месте разобраться, но вопрос же во времени. Девопс — это не открытие америки, там нет ничего сложного. Просто нужно повернуть сознание и принять это. Это не требует много времени. Буквально вопрос 1-2 недель.
Учить программирование требует больше времени, за месяц радикально изменить квалификацию невозможно, а больше работодатель ждать, думаю, не будет. В этом разница.
И настраивать девопс, имхо, не работа сисадмина, это работа инженеров.
Да, и менеджер реал-тайм сообщений я спроектировать смогу. :)
Я не очень понял Ваш обиду на программистов. Про з.п. я, кстати, согласен с Вами — труд сисадмина не менее важен чем труд инженера, и нет причин платить меньше.
«за месяц радикально изменить квалификацию невозможно» — так никто и не говорит радикально — я не зная питона потратил 2 недели чтоб переписать библиотеку с 2 на 3 и написать сервис на джанго который хранит и отображает(с графиками, js'ами и jqery'ями) данные поступающие от нее — так же могу сказать «программирование это не открытие америки, там нет ничего сложного»
«Да, и менеджер реал-тайм» — а вот это я написал чтоб подискутировать на тему того что скрыто от глаз программистов — а как вы собираетесь гарантировать realtime? напомню — это возможность гарантии обработки сообщения в установленные временные сроки
«И настраивать девопс, имхо, не работа сисадмина, это работа инженеров» — тут как назвать, главное чтобы все участники понимали суть происходящего. Так то я и сисадмином тогда не был как таковым — все мое рабочее время было сведено к автоматизации всего что увижу=)
«Я не очень понял Ваш обиду на программистов» — потому что я пока что не видел прецедентов когда сисадминов спрашивают на моменте когда планируют свое ПО, но гоняют и в хвост и в гриву когда их ПО почему то перестает работать. мб у меня это корпоративная травма=)
Думаю, что разнообразие вариантов я представляю неплохо — я 5 лет делал DevOps в Amazon, где CD пайплайны очень сложные (даже, имхо, более сложные чем необходимо).
А, что сисадминов не спрашивают при настройке, а потом они несут ответственность — это, ясное дело, неправильно, о чем говорить.
Идеальный пайплайн в вакууме — пустой пайплайн. А в реальном проекте — зависит от проекта.
На самом деле на так уж сильно и зависит. Базовые принципы контроля качества кода и хорошего CI/CD примерно одни и те же для всех проектов. И в статье, на мой взгляд, изложены разумные тезисы. Я только не понял, зачем домогаться на эту тему кандидатов.
В статье, на мой взгляд, изложены хорошие примеры куда можно стремиться. Подпишусь.
В одном из проектов у нас обязательное условие для прохождения новой версии в продакшен — это способность поднять старый бэкап и пройти smoke test (увидеть данные из поднятой базы в приложении). Это добавили операторы, потому что программисты постоянно ломали бэкапы.
А вот насчёт линтинга… После перехода на black (форматтер питона) линтинг, как класс, исчез. Есть проверка, что оно "форматировано блеком", но заставлять людей вручную ублажать пайлинт — это феерическая трата времени. Ctrl-Shift-I перед сохранением.
То же касается rustfmt и gofmt. Что есть у других языков — интересный вопрос.
Насчёт gofmt категорически не согласен — golangci-lint содержит десятки линтеров, большинство из которых действительно полезны и ловят очень много проблем, которые gofmt никаким образом не решает.
Идея с проверкой бекапов не плохая для определенных ситуаций. Вопрос, а если новая версия требует изменения в smoke tests, как вы с этим справляетесь? Храните разные версии тестов?
Идеальный пайплайн обязан как минимум: очень быстро работать, прям чтоб сделал git push и тут же всплыла уведомляшка «пайплайн выполнен», всегда запускать только нужные команды, показывать понятные сообщения об ошибках. И раз уж разговор про идеальность, то должна быть возможность локально отладить CI: позапускать джобы и подёргать триггеры без бесконечных пушей конфига.
Не согласен совершенно. Пайплайн не обязан работать быстро, более того, он не может работать быстро:
- билд требует какого-то времени (+ иногда расходы времени на сам запуск билда, такое тоже бывает)
- деплой — не быстрая штука. допустим в вашей ферме 10 серверов — вы ж не будете деплоить все 10 сразу, пользователя надо пожалеть. и даже половину не будете (если у вас серверов выделено не с запасом). Мы деплоили так чтобы 2/3 серверов обязательно были работающие. т.е. 10 серверов задеплоятся в 4 приема — 3+3+3+1
- После деплоя иногда настраиваются "паузы", чтобы проверить не полетят ли high-severity алерты, если да — то автоматический rollback. Такие паузы занимают 15-30 минут. Меньше — не имеет смысла.
- Иногда пайплайны настраивают так чтобы не деплоить, например с пятницы до воскресенья, чтобы oncall совсем уж не ишачил на выходных
- Если у вас несколько окружений (хотя бы, допустим, два — тестовое и продакшн), то все выше сказанное еще, грубо говоря, умножается на число окружений
- Интеграционные тесты тоже занимают время. Лоад тесты — тем более.
И это я еще не все упомянул.
Ну и где тут мгновенный CD? И близко нет. Не в этом его цель.
Если сверху было распоряжение поставить сканирование кода, потому что «все так делают», процесс занимает лишнее время, а в реальности отчеты по сканированию никто не читает,
если разработчики прибегают к тебе с бумагой за подписью менеджера, что Verified -1, влепленный в ревью тестами, нужно вручную убрать,
то лучше вовсе эти степы не делать, чем делать так.
Идеальный пайплайн в вакууме