Pull to refresh

Comments 32

Что это значит с точки зрения инженера-инфраструктурщика, который занимается внедрением девопса?


Т.е. внедрением DevOps философии (влияющей абсолютно на все этапы разработки/тестировния/экслуатации и на всех участников процесса) занимаются какие то отдельные люди в вакууме?

Именно с этой архитектурой администраторам и девопсам приходится сталкиваться при проведении любого интеграционного тестирования. Именно она работает на обслуживаемых ими стендах.


Кто такие эти ДевОпсы? Программисты которые могут задеплоить что угодно куда угодно? Сисадмины которые могут написать достаточно сложную системную библиотеку? Тестировщики которые понимают систему с высоты в «10000 футов»? А может быть все эти ребята вместе?

Но когда нам нужно выкатить софт действительно быстро, четко и без ошибок, силами обычных администраторов (не подкючая разработчиков конкретного продута)

Когда программисты исключительно программируют, тестировщики тестируют а сисадмины выкатывают, это кажется не DevOps.

Кажется, DevOps — это когда процессы построены таким образом, что даже средний разработчик имеет возможность без проблем выкатить свой код какой бы сложной не была система, при этом выкатить быстро, четко и без ошибок.
Потому что во первых, он понимает как оно все работает и что он делает, т.е. для него кусок его кода не является конем в вакууме.
Во вторых, он и его коллеги из эксплуатации, тестирования, ИБ и прочих отделов на славу потрудились все вместе чтобы создать такую систему.
В третьих, нет ни каких технических, организационных и бюрократических преград, чтобы это сделать.
В четвертых, если что-то пойдет не так, не будет ни каких негативных последствий, потому что система построена таким образом, что заинтересованные лица сразу же узнают, что оно пошло не так и смогут это оперативно исправить.

Хотя конечно я могу заблуждаться.
Внедрением девопса занимаются все. Но есть люди, более ответственные за это, чем все остальные. Наример, архитекторы, местные аналоги SRE, разработчики девопс-инструментария (в Сбертехе очень много своих внутренних разработок), написатели скриптов для координации CI/CD, и так далее. Есть специальные команды, ответственные за внедрение практик девопса.

В последнее время в России часто употребляют слово «девопс» в смысле должности. Это конечно, звучит несколько неграмотно, но зато позволяет не перечислять каждый раз длинный список этих «специальных особо ответственных». О ком конкретно речь в данном конкретном случае — обычно можно понять по контексту.
Все верно — devops это в первую очередь отлаженные процессы. Но разработчики сами врядли будут с нуля разворачивать эти процессы, им все равно нужен человек который будет заниматься настройкой devops среды.
Тут знакомые из СберТеха говорят, что твою статью воткнули во внутренний Confluence, потому что она хорошо саммаризует происходящее у них. Мне кажется, парни должны тебе проставиться :)
наверно первый раз читаю про девопс и не испытываю отвращения.

А это потому что про инструменты, а ты технарь. И в этом весь затык с внедренеем ДевОпса — технарей интересуют только инструменты, а Девопс это про культуру, а не про инструменты.

Инструменты как раз не интересуют вообще никак и статья не о них.
Меня очень нервирует маркетинговый буллшит, поэтому стараюсь писать только по делу. В конце концов, за очковтирательство на Хабре не платят, чтобы нести чушь еще и здесь. Вот есть вполне конкретная схема — ее и описал.
И надо отметить получилось неплохо.
Чем больше pipeline. тем дольше путь от заявки до пользователя. с учетом PM etc.
В сентябре я на приложении сбербанк-онлайн обнаружил багу — сбрасывается пароль, приходится перерегистрировать приложение. бага не критичная, но крайне не удобная, вызывает крайнее отторжение. И вот я допустим сообщил о ней, через какое время фикс окажется на продакшене?
В данной статье рассматривается только девопс внутри ППРБ. ППРБ — это корная платформа банка, дело с которой имеют сотрудники банка. А за публичные интерфейсы (и баги в нем) отвечает другая программа — ЕФС. У них даже есть блог на Хабре: https://habrahabr.ru/company/efs, и они даже уже что-то начали выкладывать на Гитхаб: https://github.com/Sberbank-Technology. С какой скоростью и как ЕФС отвечает на запросы о багах я, к сожалению, сказать не могу.
Любопытно, но в фейсбуке всего 17 тысяч человек работает, а у фейсбука и пользователей в десяток раз больше, и капитализация в десяток раз больше, и девопса у них столько, что непродохнуть.

Почему? Наверное, потому что в фейсбуке пишут код, а сбербанке внедряют аджайл годами.

От того, что пользователь Фейсбук увидит на 1 лайк больше или меньше — ничего не произойдет. Ровным счетом ни-че-го. И фиксить этот баг можно месяцами — ничего Фейсбуку не будет

Будет. Посмотрите с какой скоростью они реагируют на политические события.
А теперь пораскиньте все же мозгами — насколько более критичны ошибки в банках и насколько иная разработка. Принципиально иная. Даже странно что это приходиться жевать неглупому вроде ИТшнику
Попытался пораскинуть. Сбербанк потерял все базы и бэкапы. Убыток не более 66 ярдов. Facebook потерял все базы и все бэкапы — убыток over 500 ярдов.

Получается, база фейсбука ценнее сбербанковской примерно в восемь раз.
Фейсбук и должен реагировать на политические события быстро. Это хороший хлеб. Но то что при этом будут сбоить счетчики лайков — не страшно.

У банков не мржет быть такой избирательности.
Хмм, давно у фейсбука ~15 тысяч отделений в 83 субьектах РФ, ~80 тысяч банкоматов, требующих присутствия реальных живых людей? Не знал, ай да фейсбук
А это вопрос к вашему бизнесу — почему вам до сих пор нужны люди для обслуживания счетов. Специальный сотрудник, который показывает как и в какой последовательности на банкомате нажимать кнопки (15 тысяч отделений, 15 тысяч рабочих мест — только чтобы не сделать эргономичный интерфейс).

Гордиться числом сотрудников, на занятых автоматизацией, может только компания, которая не считает автоматизацию приоритетом.
Вы, батенька, очень тонкий тролль, браво. Но статья не об этом.
Имхо, какой бы эргономичный интерфейс не был, он не поможет пожилому, зачастую неочень хорошо видящему человеку, к тому же теряющемуся при виде всех этих достижений прогресса, оплатить коммунальные платежи. С тем же успехом можно предъявить претензии к Московскому Метрополитену за то, что они ввели должности помощников на территории метро (это такая бесплатная услуга, можно позвонить по специальному номеру и к Вам придут один или несколько человек и помогут добраться от входа в метро до выхода на нужной Вам станции).
А бабушек и прочих которые с компьютерами не на ты — расстрелять предлагаете?
Я никого не хочу расстреливать, но если бабушка может пользоваться воцапом на телефоне и не может терминалом сбербанка, то это
а) заслуга гугля (эппла) и фейсбука
б) профессиональное несоответствие дизайнера терминала сбербанка
У противопоставляемого вами Сберу ФБ интерфейс — далеко не простой, кстати.

А остальные 99% бабушек что и СМС не умеют читать? Их куда?
Добрый день! Рассматривали ли вы другие DevOps инструменты: TeamCity, YouTrack, Puppet? Используете ли вы ELK стек?
Безусловно рассматривали разное, результат рассмотрения вы видите. В будущем он может измениться. Если вы хотите продать что-то, то я — точно не тот человек, к которому стоит обращаться с такими вопросами)

Ansible в контексте статьи лучше Puppet а) интеграцией в существующую Python-инфраструктуру б) наличием множества специалистов с хорошим знанием Python в) Отсутствием агента

Про ELK стек ничего не знаю, к сожалению. Это не значит, что какие-то проекты или программы его не используют — Сбт большой :)

Отмечу только, что в ППРБ существует своя собственная система мониторинга, в недрах которой кроме самописных решений используется еще и Splunk. О мониторинге будет одна из следующих статей об Сбт на Хабре, и скорей всего — доклад на JBreak/JPoint 2018. Вы о Splunk не спрашивали, но вдруг окажется полезным :)
Спасибо за ответ. Я такой же DevOps)
Прочитал статью и вопросов осталось куча. Можно я вывалю, а вы уж сами решайте на какие отвечать
1. Что такое ППРБ
2. Статья называется «Инструментальный стандарт», но я так понял, что это стандарт не СБТ, а только некоей системы ППРБ?
3. Можно все таки немного подробностей про «дополнительная система управления сквозным процессом развертывания»? Зачем эта система? Чем обусловлено ее возникновение?
4. Судя по фразе «Финальная сборка и публикация артефактов в хранилище. Например, для Java это будет Nexus,» под каждый тип используется свой инструмент хранения артефактов? Какие?
5. Деплой на стенды выполняется чем? Какой инструментарий используется? Что то свое писали или open source?
6. Тоже про тесты. Пользуетесь стандартными флоу или свои делали?

Вопросов еще много, но пока остановлюсь :)
1. ППРБ — Платформа Поддержки Развития Бизнеса. Программа, в ходе которой разрабатывается бэкенд Банка

2. Да, это стандарт ППРБ, но скорей всего — он у всех скоро будет такой. ППРБ бежит впереди планеты всей.

3. Не могу) (на самом деле, потому что сказать особо нечего, по этой части я не спец)

4. Для хранения артефактов для передачи на прод, используется одна система хранения. Я подчеркнул про Nexus и Java, потому что стандартная реакция людей — начать ныть «вот вы банк, у вас много денег, вы можете организовать хранение, а мы — нет». Все это гнилые отмазки — берете уже существующий у вас Нексус (или Артифактори), суете туда артефакты с хэшсуммами, и уже какое-никакое хранилище есть. Напоминаю, что в Нексус можно класть не только с помощью mvn deploy, а вообще любые файлы, в т.ч. с помощью API

5. Деплой на стенды стартуется с Jenkins, который передает управление на управляющую машину Ansible, котоаря запускает плейбуки, в значительной степени состоящие из самописных плагинов на Python. Таким образом, инструментарий: Python, Ansible, Jenkins.

6. Модульные тесты — стандартный флоу. Нагрузочное и UI — сильно специфичное для конкретного проекта.
Sign up to leave a comment.