Автоматизация "сразу всего" возможна только в реальности не очень умного менеджера.
Само наличие и использование инструментов автоматизации не может вам гарантировать идемпотентность
К примеру, уменя на нескольких проектах только для одного условного "базаданных-нейм-сервис" может быть разных типов в разных количествах, поставляться либо со стороны разных клауд провайдеров, в каждом из которых своя специфика реализации и среды, либо в виде наборов кубер ресурсов, которые тоже могут быть разные например в случае использования опеншифта, либо как сервисы в опенстэк инстансах, сетевая часть варьируема, механизмы контроля доступа варьируемы, механизмы деплоя варьируемы, сорадж вообще отдельная история, и все это дополнительно еще периодически может быть частично или полностью переданно сторонним вендорам, или заказчику. Вы можете обмазаться скриптами, и так скорее всего и будет, но рано или поздно обязательно появляется дополнительное условие под которое нужно что-то менять, переписывать и так далее.
А разработка ПО в целом это не про автоматизацию? А что это за разработка ПО такая, когда постоянно находятся баги, появляются новые фичи, выпускаются релизы, а не один раз разработал и ушел? Может такую разработку надо выкинуть на помойку и не пользоваться?
А бухгалтерия это не про автоматизацию? А что это за бухгалтерия такая, когда постоянно требуется рассчитывать зарплату, а не один раз подсчитал и ушел?
А менеджмент это не про автоматизацию? Почему нельзя один раз все вопросики порешать и уйти?
До начала апокалипсиса значительное число крупных компаний, в дальнейшем ушедших из РФ имело свои центры обучения. Это был неплохой способ вкатиться, особенно на позиции, не требующих серьезной подготовки. Мне кажется, этот фактор в аналитике не учтен.
Чем этот подход принципиально лучше запуском gitlab джобы, которая собирала бы образ обычным докером и деплоем в кубер через helm install/update? В теории можно даже без репозитория образов такую схему собрать
Решительно непонятно, что мешает сделать "отправную точку в DevOps" с использованием инструментов DevOps? Может не обязательно всех и сразу, но хоть каких-нибудь?
Название статьи не вяжется с содержанием. Тут скорее про то, как автор находит оправдания неповышению зарплат. А причина простая - над ним такие же начальники, решившие за него каким будет зарплатный фонд, и если его раньше срока исчерпать автор получит люлей.
Но это не про сотрудников, справедливо ожидающих роста зп - особенно с текущей инфляцией. Это про криво организованное корпоративное планирование.
Вам бы задуматься о том как организовывать бизнес процессы таким образом, чтобы непрерывная индексация заработанных плат в рамках рынка не уменьшала прибыль за счёт минимизации остальных неявных издержек.
Удаленный формат работы делает в крупных компаниях значительное количество сотрудников не особо нужными. Речь не только об HR, часть руководящего состава, офис-менеджеры, например. Вдруг оказалось, что не так уж и необходимо тратиться на большие помещения, командировки между офисами и вот это все. Естественно нашлись люди заинтересованные в том, чтобы их просто не выгнали.
Все остальные причины борьбы компаний с удаленкой надуманные. Все решаемо в рамках реализации нормального рабочего процесса.
Ну так не надо жмотиться на отказоустойчивую архитектуру, чтобы у инженеров было время на нормальную диагностику и поиск решения проблемы. Я бы не доверял экспертному эксперту который с закрытыми глазами по расположению звезд уже за полчаса до инцидента знает причину его возникновения. Анализ должен быть полным и подробным
Статья будет начинаться со слов "Всем привет! Я работаю ДевоПсом"
Прикольно вам жить.
Автоматизация "сразу всего" возможна только в реальности не очень умного менеджера.
Само наличие и использование инструментов автоматизации не может вам гарантировать идемпотентность
К примеру, уменя на нескольких проектах только для одного условного "базаданных-нейм-сервис" может быть разных типов в разных количествах, поставляться либо со стороны разных клауд провайдеров, в каждом из которых своя специфика реализации и среды, либо в виде наборов кубер ресурсов, которые тоже могут быть разные например в случае использования опеншифта, либо как сервисы в опенстэк инстансах, сетевая часть варьируема, механизмы контроля доступа варьируемы, механизмы деплоя варьируемы, сорадж вообще отдельная история, и все это дополнительно еще периодически может быть частично или полностью переданно сторонним вендорам, или заказчику. Вы можете обмазаться скриптами, и так скорее всего и будет, но рано или поздно обязательно появляется дополнительное условие под которое нужно что-то менять, переписывать и так далее.
А разработка ПО в целом это не про автоматизацию? А что это за разработка ПО такая, когда постоянно находятся баги, появляются новые фичи, выпускаются релизы, а не один раз разработал и ушел? Может такую разработку надо выкинуть на помойку и не пользоваться?
А бухгалтерия это не про автоматизацию? А что это за бухгалтерия такая, когда постоянно требуется рассчитывать зарплату, а не один раз подсчитал и ушел?
А менеджмент это не про автоматизацию? Почему нельзя один раз все вопросики порешать и уйти?
Вы точно в it работаете с такими вопросами?
До начала апокалипсиса значительное число крупных компаний, в дальнейшем ушедших из РФ имело свои центры обучения. Это был неплохой способ вкатиться, особенно на позиции, не требующих серьезной подготовки. Мне кажется, этот фактор в аналитике не учтен.
А что вы думаете об утечке sencetive data, ставя задачи прикручивать chat gpt к жире/конфлюенсу?
Чем этот подход принципиально лучше запуском gitlab джобы, которая собирала бы образ обычным докером и деплоем в кубер через helm install/update? В теории можно даже без репозитория образов такую схему собрать
Решительно непонятно, что мешает сделать "отправную точку в DevOps" с использованием инструментов DevOps? Может не обязательно всех и сразу, но хоть каких-нибудь?
От создателей
"если чел смог забить гвоздь микроскопом, он сможет это сделать молотком"
или
"если чел смог построить землянку в лесу, он сможет управлять краном-манипулятором на стройке"
тут зависит от контекста.
А с чего вы взяли, что кластер обязательно боевой? Чем вас так пугает постгресс в тестовом энве?
Потом обеим контрольным группам дать нейросетку в помощь. Посмотреть на динамику изменения "разницы".
Название статьи не вяжется с содержанием. Тут скорее про то, как автор находит оправдания неповышению зарплат. А причина простая - над ним такие же начальники, решившие за него каким будет зарплатный фонд, и если его раньше срока исчерпать автор получит люлей.
Но это не про сотрудников, справедливо ожидающих роста зп - особенно с текущей инфляцией. Это про криво организованное корпоративное планирование.
Вам бы задуматься о том как организовывать бизнес процессы таким образом, чтобы непрерывная индексация заработанных плат в рамках рынка не уменьшала прибыль за счёт минимизации остальных неявных издержек.
Удаленный формат работы делает в крупных компаниях значительное количество сотрудников не особо нужными. Речь не только об HR, часть руководящего состава, офис-менеджеры, например. Вдруг оказалось, что не так уж и необходимо тратиться на большие помещения, командировки между офисами и вот это все. Естественно нашлись люди заинтересованные в том, чтобы их просто не выгнали.
Все остальные причины борьбы компаний с удаленкой надуманные. Все решаемо в рамках реализации нормального рабочего процесса.
Ну так не надо жмотиться на отказоустойчивую архитектуру, чтобы у инженеров было время на нормальную диагностику и поиск решения проблемы. Я бы не доверял экспертному эксперту который с закрытыми глазами по расположению звезд уже за полчаса до инцидента знает причину его возникновения. Анализ должен быть полным и подробным
Как-то плохо решена задача написания пайплайнов
Мало того, что пропущены mandatory инструкции, так и логика кривая. Зачем два по сути одинаковых стейджа билда приложения, чтобы что?