Comments 12
Как-то забавно что на КДПВ в фокусе самые девопсовые инструменты — Photoshop и Premiere (и последний открыт на весь экран)
Сисадмины как и программисты бывают разные.
Для неплохого сисадмина прочитать и понять, а иногда и поправить, код на большинстве мейнстрим языков — не проблема.
При переходе такого в DevOps акценты просто смещаются в сторону большего количества кода и меньшего ковыряния в операционке/железе.
Ключевые качества прагматичного DevOps-а:
- Усидчивость — без вопростов
- Внимание к деталям — без вопростов.
Но главное не зарываться и знать когда остановиться.
Чрезмерный перфекционизм не всегда полезен. - Аналитическое мышление — в формулировке в приведенной в статье — не соглашусь.
Противопоставлять примеры и тех. доки — зачем? У них цели разные.
Если есть готовое решение, и оно подходит, я не буду чего-то искать.
Если подходит не полностью — склонирую и допилю напильником.
- Многозадачность — нафиг, нафиг, и ещё миллиард раз нафиг!
Так никакие проекты не будут продвигаться.
В нормальной команде будет on-call дежурство, так вот именно on-call будет чинить то, что сломалось.
В это время свободные от дежурства спокойно делают запланированные таски и о факапах узнают на post-mortem.
Если вам «повезло» быть единственным DevOps на проекте, то во первых — мои соболезнования, во вторых — заставляйте всех открывать тикеты, даже для misson critical, начинайте чинить сразу, но чтоб тикет был.
Ну или сами открывайте ставя нужного человека requester-ом - Знает свои инструменты — Это не только к DevOps относится.
- Считает деньги и время — для меня большим открытием было то что я могу чего-то не делать потому, что суммарный выхлоп даст выгоды меньше чем моя зарплата за время разработки.
Или не заскриптовать таск, который хочется потому, что он прикольно на скрипт ляжет, а на самом деле не надо — он одноразовый (до сих пор иногда не могу удержаться и количество скриптов в ~/src/scratch растёт).
Если не относиться к профессии с прагматизмом и некоторой долей цинизма, выгоришь быстрее и эффекктивность будет страдать.
Мира и добра, кстати у нас есть печеньки.
Для неплохого сисадмина прочитать и понять, а иногда и поправить, код на большинстве мейнстрим языков — не проблема.
Где вы таких находите? В ентерпрайзе большинство админов в лучшем случае умеет писать небольшие скрипты на Bash или PowerShell.
Вот не знаю где их брать когда интервью делал то обычно мрак и ужас. Редко кто попадался с правильно настроенной головой.
Из личного опыта.
Мне повезло поддерживать R&D почти на всех работах и было просто любопытно что там разрабы пилят.
Пришлось освоить несколько языков на базовом уровне.
Тоесть программировать нормально я не умею, скилл и налёт часов нужен но в логике программы разберусь.
В предпоследней команде половина DevOps были выходцами из системщиков.
Так perl, python, Java вообще никого не пугали.
Не говоря уже о bash.
Хорошим тоном было найти место в коде, которое падало с ошибкой и если проблема маленькая и тривиальная то можно было к разрабу с пулл-реквестом прийти.
Но это редко было.
Разработчики в разы лучше ориентируются в коде.
А то люди сначала выставляют вилку, где верхняя планка примерно в два раза ниже, чем у ковырятеля формочек во фронтенде, и хотят за эти деньги чтоб кандидат разбирался и в сетях, и в systems engineering и код умел писать. Такие люди, как правило, все трудоустроены. И если и планируют менять работу, то с релокацией, потому что российский рынок труда адекватной их компетенциям компенсации предложить, увы, не может.
Это что, новые требования к разработчикам — не понимать, что написано на другом языке?
В это же время я как девелопер — добавляю себе работы: ищу ошибку в коде и даже пытаюсь починить баг.
А я ищу неполадки в сети или несовместимости пакетов. Тут в чистом виде проф деформация, люди ищут неполадки там, где лучше разбираются.
На мой взгляд, специалистам с бэкграундом девелопера легче освоиться в DevОps по двум причинам
А на мой взгяд, специалистам с бэкграундом админа легче освоиться в DevOps…
Очень однобокий у вас получился рассказ. На моем опыте, когда дело касается облаков, контейнеров, виртуализации, девелоперы тоже могут только громко выругаться если что-то не работает, а админы с легкостью лезут «под капот» и прописывают системные переменные для обхода прокси через пробрасывание трафика сквозь 22 порт.
Я бы сказал что DevOps это шкала между программированием и администрированием и в каждой отдельной команде человек с такой должностью находится ближе к той части где он разбирается, а команде нужно чтобы разбирался. Например у нас в проекте в задачи девопса входит организовать доставку приложения на физические машины находящиеся в чистом поле без интернета и вообще какой либо сети. Это чистый админский кейс, с использованием инструментов автоматизированного развертывания образов, тут концепты вроде terraform ломаются о суровую действительность и нужно закатать рукава с реальной железкой на столе.
В классических проектах на Java роли тестировщика, разработчика и DevOps четко разграничены, а serverless-системы – принципиально другие.
Эх ребята, все не так, все не так ребята (с)
Вообще в классическом понимании DevOps нет такой роли, есть набор практик, технологий и методологий.
DevOps должны заниматься и админы и разработка и тестирование. Если вы кого-то конкретного (админа, разработчика или тестировщика) в девопс назначаете, такой девопс у вас и получится — однобокий. Что собственно противоречит его сути.
Переквалификация в DevOps – к чему себя готовить