Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
 Re: Из разработчиков в DevOps-инженеры  [new]
bga83
Member

Откуда: Город герой Ленинград
Сообщений: 30716
Андрей Панфилов
bga83
ЗЫ devops - это и не процесс все же, а методология/подход.
интересная методология: иметь в стэке полтинник неполноценных систем и утверждать что все это каким-то образом "работает" Картинка с другого сайта.

Картинка с другого сайта.
не стоит путать методологию и конкретные инструменты. Теплое и зеленое же не путаете. Это раз. А во-вторых, если взглянуть на разработку, то количество языков программирования будет даже больше, при этом каждый из них со своими недостатками. Но это ж не значит, что на всем можно поставить крест.
23 сен 19, 20:24    [21977266]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4836
Interloper
Сейчас все больше доминирует подход "инфраструктура как код", поэтому девопс-инженеры ближе к программистам, чем к сисадминам. Само направление системного администрирования постепенно сокращается, поскольку распространение получают облачные инфраструктуры и сервисы, к которым привычное системное администрирование малоприменимо.


Этому сто лет в обед.
На этом принципе весь Unix построен.
sh-скрипты для автоматизации администрирования писали еще до появления термина DevOps.
24 сен 19, 05:41    [21977451]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4836
Андрей Панфилов
bga83
ЗЫ devops - это и не процесс все же, а методология/подход.
интересная методология: иметь в стэке полтинник неполноценных систем и утверждать что все это каким-то образом "работает"


Вообще то работает.
Например Jenkins работает давно и надежно.
Docker для разработки очень приятна штука.
Помню как впервые устанавливал WebSphere 7 на Linux - то еще было приключение (Для разработки если что).

Все эти инструменты от программистов, для программистов.
Ну в связи с тем, что большинство из них OpenSource (читай халява), то все "удобства во дворе".
Основной интерфейс CLI, система мониторинга, через текстовые логи и т.д - такой вот олдскульный Unix-way :-)
24 сен 19, 05:47    [21977452]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3334
bga83
не стоит путать методологию и конкретные инструменты. Теплое и зеленое же не путаете. Это раз.
Я не путаю, методология - это то что описано в стандартах (ITIL, CobIT, ISO/IEC 20000), а у DevOps вся методология заключается в лозунге "мы за все хорошее, против плохого"

bga83
А во-вторых, если взглянуть на разработку, то количество языков программирования будет даже больше, при этом каждый из них со своими недостатками. Но это ж не значит, что на всем можно поставить крест.
Ну вот тут как раз вы путаете "теплое и зеленое", разнообразие ЯП - это результат эволюции CS, более того, за довольно существенным количеством ЯП стоит реальная наука. При этом "рынок" между ЯП более-менее поделен: никому в голову не приходит писать микрокод контроллеров на петоне, а сайты на asm, ну и в вакансиях как правило не требуют одновременного знания петона и asm, чего нельзя сказать о DevOps - там такая помойка, что требования пишут кто во что горазд, и наличие великого множества различных полуработоспособных инструментов - это скорее показатель несостоятельности подхода как такового: вроде топим за то, что DevOps - крутые чуваки, одновременно разработчики и администраторы, а на выходе получаем кучу разрозненного кое-как работающего дерьма, хотя концепции уже больше 10 лет.
24 сен 19, 08:31    [21977483]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3334
mad_nazgul
Вообще то работает.
Например Jenkins работает давно и надежно.
Вы совершенно зря в качестве примера достойного ПО приводите Jenkins - он как раз яркий представитель полной несостоятельности DevOps, ну вот серьезно, основная его концепция такая "если хотите чтобы оно хоть как-то шевелилось, то обмажтесь малосовместимыми сомнительного качества плагинами, а если все совсем уж плохо, то мир программирования на groovy и shell вас ждет с распростертыми объятиями", при этом я бы еще понял посыл в духе "у нас тут плагины пишут энтузиасты, соответственно плагины покрывают не все ситуации и имеют тенденцию содержать ошибки, поэтому пул-реквесты приветствуются", однако там вообще все иначе, а именно: "идите нахер со своими пул-реквестами, как-будто нам больше заняться нечем"
24 сен 19, 09:05    [21977502]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1773
Андрей Панфилов
Ну вот тут как раз вы путаете "теплое и зеленое", разнообразие ЯП - это результат эволюции CS, более того, за довольно существенным количеством ЯП стоит реальная наука.


Если посмотреть "топовые" ЯП то там никакой теории, одни жертвы аборта - что С++, что java, что JavaScript.

Андрей Панфилов
DevOps - там такая помойка, что требования пишут кто во что горазд, и наличие великого множества различных полуработоспособных инструментов - это скорее показатель несостоятельности подхода как такового


К девопсу ближе ситуация с библиотеками. Для каждого дела есть выбор библиотек.
Так и тут - есть система mesos/kubernates, есть puppet/ansible/..., есть consul-и-что-там ещё, есть zabbix/prometheus/graphite и т.д. и т.п.

А базой всему этому почти всегда служит linux - вот это можно ЯП считать.
24 сен 19, 10:11    [21977575]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
bga83
Member

Откуда: Город герой Ленинград
Сообщений: 30716
mad_nazgul
Interloper
Сейчас все больше доминирует подход "инфраструктура как код", поэтому девопс-инженеры ближе к программистам, чем к сисадминам. Само направление системного администрирования постепенно сокращается, поскольку распространение получают облачные инфраструктуры и сервисы, к которым привычное системное администрирование малоприменимо.


Этому сто лет в обед.
На этом принципе весь Unix построен.
sh-скрипты для автоматизации администрирования писали еще до появления термина DevOps.
есть пара моментов:
- IaC(infrastructure as a code) и configuration management(куда с большой натяжкой sh скрипты можно притянуть) это все же разные вещи. IaC именно про инфраструктуру - какие именно сервера нужны, с какой спецификацией, как должны быть соединены друг с другом, какие дополнительные сервисы нужны. А configuration management уже следующий слой так сказать и он про то как именно эти сервера должны быть сконфиурированы внутри.
- шел скрипты используют процедурный подход, в то время как современные configuration management тулы(ansible/puppet/salt/chef), они про декларативный метод описания конечного состояния. Несмотря на то что задачи решаются плюс-минус одинаковые, но это совершенно разные уровни.


Андрей Панфилов
mad_nazgul
Вообще то работает.
Например Jenkins работает давно и надежно.
Вы совершенно зря в качестве примера достойного ПО приводите Jenkins - он как раз яркий представитель полной несостоятельности DevOps, ну вот серьезно, основная его концепция такая "если хотите чтобы оно хоть как-то шевелилось, то обмажтесь малосовместимыми сомнительного качества плагинами, а если все совсем уж плохо, то мир программирования на groovy и shell вас ждет с распростертыми объятиями", при этом я бы еще понял посыл в духе "у нас тут плагины пишут энтузиасты, соответственно плагины покрывают не все ситуации и имеют тенденцию содержать ошибки, поэтому пул-реквесты приветствуются", однако там вообще все иначе, а именно: "идите нахер со своими пул-реквестами, как-будто нам больше заняться нечем"
проблемы с плагинами реально существуют. года 3 назад понимал фича-реквест для одного клаудного плагина Jenkins, энтузиасты довольно быстро(ну фиса реально напрашивалась сама собой) модифицировали код и подняли мерж рекверс, после чего года полтора от мейнтеннера хоть какой-то реакции пытались добиться

а касаемо необходимости использовани groovy - ну так никто не говорил что будет легко. Сделать один универсальный инструмент с одной красной кнопкой "сделать все хорошо" для всех кейсов просто не реально. тут уже отмечали что devops инженеры тоде уже пишут код массово, так же как и программисты с единственным отличием, что задачи этого кода несколько иные. Доводилось видеть проет, где гед различного кода автоматизации со стороны devops-ов было раза в полтора больше нежели кода самого приложения вокруг которого все это было создано.
Андрей Панфилов
bga83
не стоит путать методологию и конкретные инструменты. Теплое и зеленое же не путаете. Это раз.
Я не путаю, методология - это то что описано в стандартах (ITIL, CobIT, ISO/IEC 20000),
методология и стандарт это разные вещи все же
24 сен 19, 10:36    [21977608]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4836
bga83
есть пара моментов:
- IaC(infrastructure as a code) и configuration management(куда с большой натяжкой sh скрипты можно притянуть) это все же разные вещи. IaC именно про инфраструктуру - какие именно сервера нужны, с какой спецификацией, как должны быть соединены друг с другом, какие дополнительные сервисы нужны. А configuration management уже следующий слой так сказать и он про то как именно эти сервера должны быть сконфиурированы внутри.
- шел скрипты используют процедурный подход, в то время как современные configuration management тулы(ansible/puppet/salt/chef), они про декларативный метод описания конечного состояния. Несмотря на то что задачи решаются плюс-минус одинаковые, но это совершенно разные уровни.


Так и то и другое "бородатые админы" еще в нулевых делали одной левой.

IaC - портянки sh-скриптов для init'ов

Плюс конфигурационные файлы хорошие админы выносили отдельно.

Мостодноты вообще могли в C и писали для своих нужд "прикладушки".

Поэтому IaC CM и прочее, это просто маркетинговый булшит от евангелистов.

В DevOps отличается от обычного администрирования, только - "фигак-фигак и в продакшен" и "быстро поднятое не считается упавшим".

Все остальные "страшные слова" нужны чтобы продать эти два кейса.
24 сен 19, 15:22    [21978070]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4836
Андрей Панфилов
Вы совершенно зря в качестве примера достойного ПО приводите Jenkins - он как раз яркий представитель полной несостоятельности DevOps, ну вот серьезно, основная его концепция такая "если хотите чтобы оно хоть как-то шевелилось, то обмажтесь малосовместимыми сомнительного качества плагинами, а если все совсем уж плохо, то мир программирования на groovy и shell вас ждет с распростертыми объятиями", при этом я бы еще понял посыл в духе "у нас тут плагины пишут энтузиасты, соответственно плагины покрывают не все ситуации и имеют тенденцию содержать ошибки, поэтому пул-реквесты приветствуются", однако там вообще все иначе, а именно: "идите нахер со своими пул-реквестами, как-будто нам больше заняться нечем"


Возможно. Я говорю, со стороны "тупого" программиста.
Везде где я сталкивался с Jenkins он работал и "есть не просил".
Аналогично с docker'ом.
24 сен 19, 15:24    [21978073]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
bga83
Member

Откуда: Город герой Ленинград
Сообщений: 30716
mad_nazgul
bga83
есть пара моментов:
- IaC(infrastructure as a code) и configuration management(куда с большой натяжкой sh скрипты можно притянуть) это все же разные вещи. IaC именно про инфраструктуру - какие именно сервера нужны, с какой спецификацией, как должны быть соединены друг с другом, какие дополнительные сервисы нужны. А configuration management уже следующий слой так сказать и он про то как именно эти сервера должны быть сконфиурированы внутри.
- шел скрипты используют процедурный подход, в то время как современные configuration management тулы(ansible/puppet/salt/chef), они про декларативный метод описания конечного состояния. Несмотря на то что задачи решаются плюс-минус одинаковые, но это совершенно разные уровни.


Так и то и другое "бородатые админы" еще в нулевых делали одной левой.

IaC - портянки sh-скриптов для init'ов


еще раз для тех кто не понял с первого раза - IaC это про создание инфраструтуры, когда портянки sh скриптов еще попросту негде запускать
25 сен 19, 07:51    [21978557]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
lappy89
Member

Откуда:
Сообщений: 44
mad_nazgul
IaC - портянки sh-скриптов для init'ов

Плюс конфигурационные файлы хорошие админы выносили отдельно.

Мостодноты вообще могли в C и писали для своих нужд "прикладушки".

Всё это было невероятно говённого качества. Поделия уровня студента, который на половину пар по программированию сходил, а другую решил скипнуть, ну а что, цикл фор изучил, и хватит, научился.
Причём ещё и в одно лицо разработано, никаких SCM, документация уровня "если сломается, перезапустите службу", код нечитабелен, никаких DRY и KISS в помине нет, ну про тулзы анализа кода и речи не шло. Как следствие, починить это дерьмо без участия самого творца было трудно.
25 сен 19, 10:54    [21978682]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3334
mad_nazgul
Возможно. Я говорю, со стороны "тупого" программиста.
Везде где я сталкивался с Jenkins он работал и "есть не просил".
Аналогично с docker'ом.
Есть проблема, вот что пишут в книжке https://www.amazon.com/dp/0321601912?tag=contindelive-20 :
Jez Humble
The whole team should regularly gather together and hold a retrospective on the delivery process. This means that the team should reflect on what has gone well and what has gone badly, and discuss ideas on how to improve things. Somebody should be nominated to own each idea and ensure that it is acted upon. Then the next time the team gathers, they should report back on what happened. This is known as Deming cycle: plan, do, study, act
т.е. иными словами, то что у вас там где-то установлен дженкинс, вообще никак не означает что у вас есть DevOps и Continues Delivery в частности, потому что там должны быть всякие Collaboration, Continues Improvement (привет ITIL) и пр. составляющие, от того что кто-то там установил дженкис и настроил в нем триггеры на создание пул-реквостов с запуском clean install совершенно не означает что после этого человек стал DevOps, а в компании появились соответствующие практики. Лично я в женкинс добавляю фичи примерно каждый месяц (раньше, в самом начале, было чуть ли не каждую неделю) и примерно на второй итерации я смог убедиться что это ПО - суть помойка.
25 сен 19, 12:38    [21978834]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4836
bga83
еще раз для тех кто не понял с первого раза - IaC это про создание инфраструтуры, когда портянки sh скриптов еще попросту негде запускать


Так это и было создание инфраструктуры.
Или IaC оно в вакууме?!
Инфраструктуру создавали не на "брендированных" железках, а на PC-ках.
И везде был Linux, как основа инфраструктуры, sh-скрипты как клей для нее.
25 сен 19, 13:39    [21978893]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4836
lappy89
Всё это было невероятно говённого качества. Поделия уровня студента, который на половину пар по программированию сходил, а другую решил скипнуть, ну а что, цикл фор изучил, и хватит, научился.
Причём ещё и в одно лицо разработано, никаких SCM, документация уровня "если сломается, перезапустите службу", код нечитабелен, никаких DRY и KISS в помине нет, ну про тулзы анализа кода и речи не шло. Как следствие, починить это дерьмо без участия самого творца было трудно.


И... работало ведь :-)
25 сен 19, 13:41    [21978896]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3334
bga83
а касаемо необходимости использовани groovy - ну так никто не говорил что будет легко. Сделать один универсальный инструмент с одной красной кнопкой "сделать все хорошо" для всех кейсов просто не реально.
Я могу согласиться разве что с тем, что случаи бывают разные, однако ситуация с CI/CD (по крайней мере в OpenSource стэке, в майкрософте все выглядит на порядок стройнее) выглядит довольно плачевно. Ну вот довольно тривиальные ситуации:
- деплоить в жавские сервера приложений никто толком не умеет, ладно, хрен с ним со всякими коммерческими реализациями типа вебсферы, но он даже и в свободные деплоить не умеет, меж тем я беру агента из https://codehaus-cargo.github.io/cargo/Containers.html, настраиваю плагин для maven и у меня все работает (правда CD тут получается нафиг не нужна). Т.е. сделать-то не сложно, при этом там во всяких форумах постоянно нытье про то что не умеет (т.е. фича востребована), а до сих пор никто не сделал
- ладно, забъем на то что можно делать через maven, а будем делать как рекомендуетсячерез жопу: выполнять по ssh какие-то стремные наборы команд (т.е. у нас с ходу возникает портянка на шеле, еще и в ssh обернутая, кто-то правда может догадаться что можно сценарий или правильно параметризовать и раскатать на все сервера, либо генерить и копировать в рантайме - здравствуй помойка), ну вот никто до сих пор не написал нормальные сценарии запуска тех же серверов приложений, чтобы можно было точно по exit code понять запустилось оно или нет, хотя задача на самом деле тривиальная
- ладно, фиг с ним с жавскими серверами приложений, вот другая задача: я хочу гонять интеграционные тесты на определенных данных (может их кто специально готовит, может с я продуктовой среды украл), для этого мне нужно-то всего ничего, а именно:
-- интеграция с СРК, или хотябы с СУБД, чтобы можно было быстренько делать/разворачивать бэкапы
-- какой-то реестр, чтобы можно было привязывать бранчи разработки к бэкапам
ну вот в итоге ничего этого нигде нет и не особо-то и понятно толи все подряд городят колхоз, толи никто интеграционные тесты не делают (я чет склоняюсь к последнему, потому что последний раз мне заявили что-то в духе: раз в проекте используются средства рефакторинга СУБД, то бэкапы делать не нужно)
bga83
Андрей Панфилов
пропущено...
Я не путаю, методология - это то что описано в стандартах (ITIL, CobIT, ISO/IEC 20000),
методология и стандарт это разные вещи все же
Я беру книжку по ITIL и читаю про Release Management, там довольно недвусмысленно расписано каким образом выпускаются релизы, т.е. что нужно сделать перед релизом, что во время, кто принимает решение об откате и пр. - ну процесс как процесс, в DevOps же говорят: процессы это прошлый век - скучно и не интересно, у нас вместо процессов будет Collaboration, другими словами: заказчику поставили какую-то непонятную хрень, он начал жаловаться, что документации нет никакой, а ему в ответ: мы документацию вышлем как только заимпрувим свой процесс поставки, подождите полгода.
25 сен 19, 13:49    [21978907]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26735
Андрей Панфилов
bga83
а касаемо необходимости использовани groovy - ну так никто не говорил что будет легко. Сделать один универсальный инструмент с одной красной кнопкой "сделать все хорошо" для всех кейсов просто не реально.
Я могу согласиться разве что с тем

Вы можете согласиться хоть с чем-то в чужом мнении, отличном от вашего? © не верю :)
25 сен 19, 14:09    [21978929]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3334
skyANA
Вы можете согласиться хоть с чем-то в чужом мнении, отличном от вашего? © не верю :)
Ну вы всегда можете предъявить ресурс с вменяемыми практиками, только DevOps без рассказов о том, что в Зеленограде существует доморощенный SaaS который сам себя оптимизирует. А пока с этими DevOps какая-то печаль: вот берем к примеру довольно популярного в майкросовтовском стэке спрута, смотрим как деплоить изменения БД: https://octopus.com/docs/deployment-examples/sql-server-databases - один видосик, две статьи (про VS несчитается если что, там картинки унылые) и ни одна зараза не написала, что перед установкой не плохо было бы сделать бэкап. Колхозники, наверное предполагается что DevOps после ожидаемого и неминуемого обсера поколлаборируют и добавят в пайплайн бэкапы.
25 сен 19, 14:26    [21978952]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26735
Андрей Панфилов
в Зеленограде существует доморощенный SaaS который сам себя оптимизирует

доморощенный? :) типа разработанный в Зеленограде? ну да, существует :)
25 сен 19, 14:32    [21978959]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26735
Андрей Панфилов
ресурс с вменяемыми практиками, только DevOps

доклады с DevOops конфы, с HashiConf...
25 сен 19, 14:35    [21978964]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26735
Андрей Панфилов
ни одна зараза не написала, что перед установкой не плохо было бы сделать бэкап
напоминает: никто не написал, что кота в микроволновке сушить нельзя :)
25 сен 19, 14:37    [21978967]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3334
skyANA
Андрей Панфилов
ни одна зараза не написала, что перед установкой не плохо было бы сделать бэкап
напоминает: никто не написал, что кота в микроволновке сушить нельзя :)
Хрен его знает что вам что напоминает, вот я открываю книгу по специальности и читаю:
4.2.5 Remediation planning
No change should be approved without having explicitly addressed the question
of what to do if it is not successful. Ideally, there will be a back-out plan, which
will restore the organization to its initial situation, often through the reloading of a
baselined set of CIs, especially software and data. However, not all changes are
reversible, in which case an alternative approach to remediation is required. This
remediation may require a revisiting of the change itself in the event of failure, or
may be so severe that it requires invoking the organization’s business continuity
plan. Only by considering what remediation options are available before
instigating a change, and by establishing that the remediation is viable (e.g. it is
successful when tested), can the risk of the proposed change be determined and
the appropriate decisions taken.
Теперь смотрим что там у DevOps, https://help.octopus.com/t/how-to-configure-sql-database-and-file-system-backup-for-octopus-deployment-project/8022 :

support
Hi,

We have a documentation page 20 that you can use to determine what you need to backup to ensure that all your Octopus data is properly backed up.

I hope that helps!

Thank you and best regards,
Henrik
Офигеть, суппорт даже вопрос не в состоянии прочесть, ладно, потом исправился, читаем документацию: https://library.octopus.com/step-templates/34b4fa10-329f-4c50-ab7c-d6b047264b83/actiontemplate-sql-backup-database - видим любимую портянку говнокода, в этот раз уже на PowerShell, о СРК там никто и не слышал ничего.
25 сен 19, 14:50    [21978982]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
bga83
Member

Откуда: Город герой Ленинград
Сообщений: 30716
Андрей Панфилов
и ни одна зараза не написала, что перед установкой не плохо было бы сделать бэкап.
так может потому что рассчитано не на обьезьян все же , которым надо напоминать о необходимости бекапов
25 сен 19, 15:15    [21979000]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3334
bga83
так может потому что рассчитано не на обьезьян все же , которым надо напоминать о необходимости бекапов
Непонятно на кого рассчитано, вот выше пишут:

skyANA
доклады с DevOops конфы, с HashiConf...
Прямо представил себе ситуацию:
- заказчик: чего это у нас все сломалось-то?
- DevOps: вы меня на конференцию не пустили, вот расхлебывайте теперь.

т.е. "не обезьяны" за 15 лет не смогли ни книжек толковых написать, ни ПО работоспособное сделать, так получается? Вот серьезно, что мешает в этом спруте сделать совершенно очевидную вещь: если добавляем миграцию СУБД, то вверху лепим шаг с бэкапом, чтобы "не обезьяна" не делала бэкап осознанно, а не потому что она на конференции не ходила и книжки по специальности не читала?
25 сен 19, 15:24    [21979010]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
WebSharper
Member

Откуда:
Сообщений: 464
Андрей Панфилов,

Не разбираюсь не в девопс ни в итилах, но мнение имею:

Говорят, итил не противоречит девопс.

автор
При этом методология DevOps обеспечивает более высокую скорость разработки, являясь аналогом современного скоростного шоссе. Однако следует помнить, что правила, например, безопасности на высокоскоростном шоссе не отличаются от таковых на "старом" маршруте! При этом правила в контексте ИТ устанавливаются с использованием общепризнанных методологий, таких, как ITIL.


Говорят, итил v4 включает в себя девопс.

автор
The new version encourages fewer silos, increased collaboration, facilitating communication across the whole organization, and the integration of Agile and DevOps into ITSM strategies. ITIL V4 is designed to be more customizable and flexible. In essence, the new version encourages a more holistic view of IT.


То, что октопус не предлагает бекапа, так и раньше бородатому админу сам в скрипт миграции бекап не дописывался, не?

А вы что думаете по этому поводу?
25 сен 19, 15:36    [21979024]     Ответить | Цитировать Сообщить модератору
 Re: Из разработчиков в DevOps-инженеры  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26735
Андрей Панфилов,

у меня сложилось чёткое впечатление, что вы судите о DevOps исключительно по своему неудачному опыту:
пришёл Андрюша к заказчику, а у него там Octopus, который Андрюша в первый раз увидел, и надо разбираться, и это оказалось не просто

я пользуюсь GitLab, TeamCity, продуктами от HashiCorp
и не было у меня проблем разобраться, ни с документацией, ни с поддержкой
25 сен 19, 15:52    [21979035]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
Все форумы / Работа Ответить