Комментарии 12
Честно говоря, не согласен по большинству пунктов.
Тут проблемы и способы решения не на уровне джуниора, а на уровне вообще не очень дружащего с логикой человека.
Подробнее
Вместо того, чтобы долго копаться и пытаться запустить сервис самостоятельно — сходить к разработчикам, которые писали код и точно знают, как всё работает и что нужно для запуска.
Это как бы логично, что разработчик должен показать как работает сервис, и вообще запустить в заранее настроенной среде. В проекте должна быть инфраструктура, про которую разработчика знакомят, и еще до написания сервиса согласовывается как сервис будет запускаться, сколько ресурсов для него требуется в тестовой и продакшен среде и так далее. Ситуация когда готовый сервис попадает девопсу, а он самостоятельно думает как и где его запустить без консультации - немного нонсенс.
Не менеджерить свою задачу
Эм.. это же твоя задача. Ты ее делаешь, ты привлекаешь других участников и отвечаешь за весь процесс.
Перекладывать ответственность при разборе инцидентов
Это тоже совершенно естественное поведение. Если есть ошибка, и девопс не понимает ее смысла, нужно выяснить кто понимает ее смысл и уже только после этого перекидывать задачу.
Но это не то, чтобы поведение только девопс инженера. Это задача менеджера и культуры в проекте организовать процесс так, что любой на кого упал инцидент, должен разобраться в проблеме достаточно глубоко, чтобы перенаправлять инцидент уже осознанно и если инцидент перекидывался несколько раз - такие случаи разбирать.
Использовать временные решения вместо продуманных
Внедрение продуманного решения может занять время, а продакшен не может стоять. Поэтому временные решения - отличная идея. Главное не забывать о слове "временные" в термине "временные решения".
Внедрять новые инструменты и не рассказывать об этом
Это вообще не проблема джунов, а вопрос вообще любого специалиста. Любая новая зависимость - инструмент, библиотека, что-нибудь еще - это еще одна зависимость, еще один кусок для поддержки, проверки и так далее. Внедрение нового чего-либо следует согласовывать с тим-лидом(тех лидом) или архитектором.
Не вникать в показатели эффективности
Ситуация: есть задача настроить мониторинг сервиса.
Кто ставил эту задачу с того и спрос. Я не очень понимаю как может быть задача "настроить мониторинг сервиса" без детализации. Нужные метрики или требования к мониторингу должны быть частью этой задачи.
Не прогнозировать последствия
Ситуация: все участники проекта — разработчики, заказчик — подтвердили, что можно отключать одну из виртуальных машин
Мониторинга нет, даже девопсы не знают что крутится на виртуальной машине?
Опять таки не вижу, чтобы это была ошибка джуна. Это прям ошибка всего проекта и подходу к инфраструктуре.
Но этот пункт, наверное первый, где я полностью согласен - девопс, как разновидность сисадмина, первый кто обязан думать о бэкапах и восстановлении, поэтому в любых действиях, которые меняют конфигурацию, это его обязанность предусмотреть восстановление и откат.
P.S. В общем основные мои претензии к статье - что ни одна из "ошибок" не относится к "джуну Девопс". Все ошибки относятся либо ко всем участникам проекта, либо к архитекторам/менеджерам/тимлидам, которые вообще никак не настраивают процессы.
Ситуация когда готовый сервис попадает девопсу, а он самостоятельно думает как и где его запустить без консультации - немного нонсенс.
Странно, а предыдущие пару десятков лет - это как-то работало. Обычная задача, когда системному администратору нужно запустить сервис. Администратор читает документацию и запускает сервис. Если обнаруживает проблемы - как минимум создаёт баг-репорты разработчику сервиса, а как максимум - исправляет и отправляет разработчику готовый патч. И вдруг внезапно появилось DevOps и древнее знание куда-то потерялось.
Ок, а где сисадмин запускает этот сервис?
То есть ни разу не обсуждалось сколько нужно cpu/mem/disk space для сервиса?
Просто почитал документацию и пошел запускать. Видимо всегда под рукой есть свободный сервер с бесконечными ресурсами и бесплатно. И сервис никогда не тестировался, то есть ему qa/pre-prod енвайрнменты не нужны, сразу в продакшене запускаем?
Багрепорты именно сисадмин создает? Патчи сисадмин создает, реверсинженерингом?
Девопс инженер - это просто разновидность сисадминов, а не боги на все руки.
Ок, а где сисадмин запускает этот сервис?
Хм... Может я не понимаю вопроса, но на контролируемых этим администратором ресурсах.
То есть ни разу не обсуждалось сколько нужно cpu/mem/disk space для сервиса?
Э-э-э... с кем? Администратору поставлена задача запустить такой-то сервис. Если он считает, что у него не достаточно ресурсов для запуска этого сервиса - он об этом сообщается поставившему такую задачу. Если ресурсов достаточно - запускает сервис. Честно говоря, вопроса вообще не понял.
Просто почитал документацию и пошел запускать.
Да. А что в этом такого? Собственно, а как по другому. Администратору поставили задачу - он её выполняет. Если системный администратор в процессе столкнулся с какой-то проблемой и он не может её решить самостоятельно - сообщил об этом тому, кому положено в этой организации.
Видимо всегда под рукой есть свободный сервер с бесконечными ресурсами и бесплатно.
Э-э-э... Почему бесконечными и почему бесплатно? Системный администратор администрирует какой-то ресурс. Это могут быть сервера в серверной, в дата центре, в облаке. Если всё это загружено под завязку и новый сервис невозможно запустить в эксплуатацию - системный администратор сообщает об это ответственному за эти вопросы в этой организации. Если свободные ресурсы есть - системный администратор запускает новый сервис и настраивает всё, что необходимо для его эксплуатации с требуемым в этой организации качеством.
И сервис никогда не тестировался, то есть ему qa/pre-prod енвайрнменты не нужны, сразу в продакшене запускаем?
Это зависит от постановки задачи. Какую и как задачу поставят системному администратору - так и таким образом и будет сделано.
Багрепорты именно сисадмин создает?
На да. А кто это за него сделает. Вот системный администратор запускает, ну пусть к примеру будет squid (ну или opensmtpd), да не важно что, и оно у него, к примеру, падает. Или там выжирает всю память. Или еще какое-нибудь аномальное поведение. Кто еще за системного администратор создаст баг репорт?
Патчи сисадмин создает, реверсинженерингом?
Да, именно он. При условии, если у него хватает на это опыта. И это, кстати, одно из отличий опытного системного администратора - от неопытного (или эникейщика). Только при чём тут реверсинжениринг. У администратора, как правило, есть исходники сервиса. Он может найти ситуацию, как воспроизвести проблему. Ну а раз уж нашёл, то возможно может и исправить её. Ну а потом сам бог послал сообщить об этом разработчикам, да приложить своё решение. Смотришь, в апстриме эту проблему и поправят. А пока будет эксплуатировать свое решение.
Девопс инженер - это просто разновидность сисадминов, а не боги на все руки.
При чём тут боги? Обычное системное администрирование. Я таким лет 15 занимался, да и сейчас еще бывает.
Хм... Может я не понимаю вопроса, но на контролируемых этим администратором ресурсах.
Администратор их администрирует, а не рожает.
Э-э-э... с кем? Администратору поставлена задача запустить такой-то сервис. Если он считает, что у него не достаточно ресурсов для запуска этого сервиса - он об этом сообщается поставившему такую задачу. Если ресурсов достаточно - запускает сервис. Честно говоря, вопроса вообще не понял.
Ок, по вашему пришел разработчик к админу и сказал вот сервис. А админ говорит а у менят нет ресурсов. Я тебе сообщил. Все?
Э-э-э... Почему бесконечными и почему бесплатно? Системный администратор администрирует какой-то ресурс. Это могут быть сервера в серверной, в дата центре, в облаке. Если всё это загружено под завязку и новый сервис невозможно запустить в эксплуатацию - системный администратор сообщает об это ответственному за эти вопросы в этой организации. Если свободные ресурсы есть - системный администратор запускает новый сервис и настраивает всё, что необходимо для его эксплуатации с требуемым в этой организации качеством.
Все почти так. Но. Если к вам пришел разработчик с готовым сервисом, то очень странно, что до этого момента он к вам не приходил и не договаривался об инфраструктуре. И сервис разрабатывался и тестировался где-то в черной дыре, ресурсы для тестовых сред на него не выделялись и вообще никто в компании не в курсе что уже год как пилят новый сервис. Вот только когда он готов, идут к сисадмину чтобы он его просто запустил.
В нормальном случае требования оговариваются заранее, так как выделить дополнительные ресурсы может занять не 1 минуту, а очень непредсказуемое время. В нормальном случае сервис и его требования вообще оговариваются заранее, чтобы не было случая, когда не особо нужный сервис требует дохрена ресурсов, которые проект не готов оплачивать.
Поэтому это все делается не во время сдачи сервиса "сисадмину", а в процессе разработки. Разработчики тоже должны знать с какой стороны ограничения по ресурсам есть в организации.
Багрепорты именно сисадмин создает?
На да. А кто это за него сделает. Вот системный администратор запускает, ну пусть к примеру будет squid (ну или opensmtpd), да не важно что, и оно у него, к примеру, падает. Или там выжирает всю память. Или еще какое-нибудь аномальное поведение. Кто еще за системного администратор создаст баг репорт?
Багрепорты обычно лучше всех пишут QA инженеры и сами разработчики. Если сервис выжирает всю память, почему это происходит внезапно на продакшене? Никто не тестировал никогда?
Да, именно он. При условии, если у него хватает на это опыта. И это, кстати, одно из отличий опытного системного администратора - от неопытного (или эникейщика). Только при чём тут реверсинжениринг. У администратора, как правило, есть исходники сервиса.
Откуда у администратора исходники? Зачем они ему?
Смотришь, в апстриме эту проблему и поправят. А пока будет эксплуатировать свое решение.
Вы можете как-то разобраться с апстримом, и понять что девопс отличается от сисадмина тем, что нет апстрима, код разрабатывают прямо тут с нуля, и администратор в коде не копается. Максимум конфиги.
При чём тут боги? Обычное системное администрирование. Я таким лет 15 занимался, да и сейчас еще бывает.
Сколько багрепортов отписали в какие-либо ECR системы или не опен-сорс продукты? А сколько патчей отправили?
+1 пункт: не изучать основ (операционные системы, Linux, сети)
"девопсер" это корректный термин?
А кто такой девопс? Объясните мне наконец. Что девопс должен уметь? В моей картине мира, девопс это разработчик, который помимо разработки веб-сервисов ещё умеет заниматься развертыванием. В частности настройкой CI/CD, облачных платформам, докеров с кубернетусами. Так же этот разработчик должен знать нюансы технологий в духе чем отличается RabbitMQ от Kafka и как этот все настраивать, что бы выдерживало нагрузку, как и за чем нужно следить, что бы продакшн не лег.
То есть это архитектор или техлид проекта, человек с большим опытом и знанием технологий к которому сложно применить слово джуниор.
Но я почему-то вижу курсы которые сделают тебя девопсом после курса по питону. Видимо Джуниор девопс, это тот кто пишет скрипты на питоне и что-то там автоматизирует фул-тайм.
Так если Джун скрипты пишет, может оставим его в покое. Дяди посерьёзнее это поревьювят и если что-то не так -- исправят.
Девопс это не разработчик.
Это сисадмин, который отвечает за инфраструктуру компании, в которой идет разработка продукта. Следовательно его инфраструктура включает не локальную сеть компании и 1с у бухгалтера, а сервера, где происходит сборка, тестирование, разворачивание и поддержка продукта, который разрабатывают.
Ну и автоматизация/участие в создании воркфлоу всего этого по возможности.
Понятно, что для автоматизации нужно уметь писать код, но не обязательно на уровне разработчика.
Девопс это также позиция, которая имеет влияние на архитектуру многих процессов, именно поэтому джуниор девопс - это моветон. Девопс обычно человек с опытом, и тут он может прийти и из разработчиков и из QA (автоматизейшн) и из сисадминов (что чаще всего происходит). Естественно каждый несет в свою обитель свои предыдущие знания, поэтому можно встретить девопсов которые и разрабатывают. Или которые занимаются вдобавок автотестами.
7 ошибок джунов в DevOps, которые мешают им стать мидлами