Hot Positions, Cool Company! NeoGames
×Закрыть

DevOps — корпоративная «лычка» для джунов

Итак, жили-были Элис и Боб. Элис заодно еще и черной была, чтоб совсем соблюсти политкорректность.

Жизнь у них была совершенно типичная, как для девяностых годов: Элис ходила в ясельки, а Боб отправлял патчи в ядро FreeBSD, поминая незлым тихим словом препода, который завалил его курсач за второй курс, так как не понял ассемблерные вставки в коде на Трупо Паскакале.

Прошло несколько лет...
Элис впервые прокатилась на БМВ (чего бы это ей не стоило), и по итогу решила стать прокурором, а значит — пора готовиться к поступлению на юридический!
Боб, тем временем, переписал открытый драйвер доступа к SCSI-дискам, и стал ответчиком в суде, и доказал права сообщества на этот драйвер (чего бы это ему ни стоило, но в данном случае любовь была исключительно в мозг, да еще и с помощью разнообразных средств, как-то SMTP, IRC и прочее... а, да, еще и в кошелек, который и так толщиной никогда не хвастался)

... и еще несколько лет...
-----
— Ты меня не любишь!
— Так, выложила макбук, айфон, ключи от машины и ВАЛИ С МОЕЙ ХАТЫ!
-----
— Сергей Петрович, падение пропускной способности на 40%!
— Пацаны, мы держим DDoS на 40 мегабит. Я воткнул затычку, НЕ ДЫШИТЕ!

... и совсем недавно
-----
— Я же умная! Я научусь! (надо признать — действительно умная) Я вот видела такой сайт со смешным именем, боберпропер или как-то так, там писали, что надо поставить систему Бубен, и можно зарабатывать деньги!
-----
— Сергей Петрович, у нас требуют сертификацию по ISO900x:xx
— Ну блин... А вот когда я предлагал ITIL, а вы требовали эфемерный DevOps, вы не знали, что заказчики захотят такое?... Ладно, разрулим...

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

www.quora.com/...​-engineer-DevOps-engineer

DevOps = Agile Dev (and QA) + Agile Ops with a shift left philosophy(I will explain shift left this shortly)

You will say

Ok I understand Agile Dev... scrum, sprint blah blah blah. How do you make ops agile?

Well the answer is Infrastructure as code and other practices
...

з силки вище DevOps kill Ops & QA:

There’s no more QA org (or at least its very small) — developers write ~90% of the automated tests
(Unit and Integration), maybe QA does the remaining 10% of above-UI automation and exploratory manual testing. The traditional view that you need QA because developers can’t be trusted to test their own code doesn’t apply — 90% of the test are theirs and if they messup, they’re on call.

Эта сказка сильно преукрашена. Просто потому, что если Сергей Петрович поднял сертификацию по ISO900x:xx, ему не придётся больше никуда валить. И если бы он чуть настойчивее предлагал ITIL, то ему бы нахрен не улыбалась Элис, потому что жирный заказчик давно бы уже отдал проект туда, где это самое ISO900x:xx, а Элис бы осталась без работы «вайти», и Сергей Петрович иногда бы остёгивал ей 20 вечнозелёных в доме полулегального досуга.

И кстати, Элис вероятнее всего зовут Ануся или Светулик, потому что только в бывшем постовке не понимают, что НЕЛЬЗЯ доверять ответственную работу ТП. Даже если она кажется простой.

Боже, храни королеву!

росто потому, что если Сергей Петрович поднял сертификацию по ISO900x:xx, ему не придётся больше никуда валить.

Увы — потом наступил 2008 и все IPO пошло по женской линии вместе с ISO9k, 27k, SOX404 иже с ними. А за ним и все спецы следом...

Я и говорил, что ЕСЛИ поднял. Потому что ISO9k+ работает независимо от IPO, и даже независимо от намерения по нему сертифицироваться. Просто работает и всё.

И для тех, у кого работает, 2008 год лишь слегка погладил мошонку языком. В отличие от тех, кто пригласил «антикрызиssных мэныджыров» сотворить чудо.

Потому что ISO9k+ работает независимо от IPO,

Эта сертификация нужна в двух случаях:
1. IPO — для того чтобы аудитор перед листингом вычитал о процессах компании из документов, а не устных интервью сотрудников
2. Для производственных контор, т.к. является обязательной во многих тендерах.

Просто работает и всё.

"Я вас умоляю"©. Эта сертификация означает не более, чем что все основные процессы компании документированы и ведутся записи операций. И с качеством этих процессов данное действо никак не пересекается и аудитором не оценивается. Если вы туда впишете, что электрик Вася в понедельник работает, а потом всю неделю бухает — это тоже прокатит, траст ми.

Так я и не говорю, что основной целью является сертификация. Если поднимать будут «ыфиктивные мэныджыры по сертификациям» — так и будет. Просуществует схема ровно на бумаге и в аккурат до выхода на IPO.

Но если поднимать будет «Сергей Петрович», фундаментально и надолго — то эти самые «ыфиктивные» полетят искать работу в другие компании, которые тоже хотят на IPO. А эта компания ещё сотню раз подумает, а нужно ли ей IPO, а если нужно — то когда и какая именно часть компании, и разумеется СКОЛЬКО на самом деле компания стоит чтобы не продешевить.

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

Как же тошно смотреть на людей, которые сокрушаются над трупом когда-то выученной матчасти и скулят по поводу того, что современники этой матчасти зачастую не знают. При этом сами почитать новую, современную матчасть, т.е. выйти из зоны комфорта — не могут. Отсутствие знаний компенсируют отсебятиной, и начинают спекулировать фактами, постоянно твердя что понятие DevOps «не устоялось». Это оно для вас, товарищи, не устоялось. Спикеры на локальных митапах помогают раскачивать лодку. А более-менее продвинутые кастомеры, приходя в Украину за аутсорсом, встречают стену непонимания и сопротивление. Опасная тенденция, господа, получите репутацию новых русских индусов. Насаждая свой ITIL всем и вся, очень часто можно спугнуть прогрессивного заказчика своим необузданным желанием раздуть саппорт билл до космических размеров.
Итак, господа, DevOps — это логическое продолжение Agile. Точка. Строится идея вокруг все тех-же проблем стейтментов — тайм ту маркет, бизнес аджилити, фейл фаст и так далее. Никаких конкретных советов или предписаний DevOps не дает, лишь общую идею разрушения стен и сайлсов внутри компании. Скрам команда должна быть самодостаточной, автономной и маленькой — и с DevOps это теперь включает в себя и инфраструктурные вопросы. Все остальное — спекуляции. Имплементация идеи описана различными практиками, такими как Lean, Six Sigmas, The Toyota Way и прочие. Если приглядеться — ничего нового, все тот же аджайл версии 2.0.
Термина DevOps Engineer, и вообще любой роли, хоть как-то подразумевающей DevOps — просто не существует. Такое название роли имеет столько-же смысла, как и Agile Engineer или Scrum Engineer. Эта выдумка гуляет преимущественно по СНГ, и сложно сказать как именно родилась эта псевдо-роль.
Исключая экзотические кейсы, когда, например, девопсом называют обычный опс — зачастую DevOps Engineer термин на локальном рынке на рынке глобальном называется SRE — Site Reliability Engineer. Это новый тип инженеров, которые фокусируются на IaaC (Infra as a Code), и должны быть частью продуктовых скрам-команд (делая их еще более self-manageable привнося свою инфраструктурную экспертизу).
Есть примеры, когда из SRE собирают отдельно стоящие команды, и как правило это либо объясняется скейлом компании либо непониманием DevOps в этой компании. Со вторым понятно, с первым поясню — когда компания очень большая, имеет смысл собрать команду отдельно стоящих SRE, чтобы они пилили внутренние инструменты и деливери платформу для всех остальных команд. Цель такой команды — сделать self-manageable все остальные команды и достичь дзена по части автоматизации (так называемый no-ops). Самые успешные примеры, которые я видел — это когда деливери платформа была способна благодаря добавлению 10-строчного конфига в гит-репозиторий автоматически развернуть промоушн пайплайны и энвайрменты для этого репозитория вообще без участия человека. Это имеет огромный смысл в гигантских компаниях, чтобы каждая команда не переизобретала колесо (бранчинг стратегию, релиз менеджмент, CI и CD и так далее) для себя, на чем компания экономит колоссальные деньги.
landing.google.com/sre/book/index.html больше здесь, для тех кто tl;dr: можно начать хотя-бы отсюда sethvargo.com/the-ten-myths-of-devops и дальше гуглить по теме.
Отдельно хочу отметить, что SRE и в частности упомянутый выше no-ops никак не конкурирует с Ops. Да, правила игры действительно меняются — все машины (ресурсы) теперь immutable, как правило кроме автоматики туда доступа не имеет вообще никто, за мануальные ченджи начинают бить по рукам (если предыдущий пункт не сработал). Но тем не менее, за любым клаудом все-равно где-то стоит железка, которая нуждается в обслуживании, так же этим железкам нужна сеть, маршрутизация, ну и принтеры в конце-концов тоже кому-то нужно заправлять. Да, правила игры меняются, но луддиты в свое время не смогли обратить изменения — вот и вам советую учиться и развиваться. Пирога хватит на всех, в конце концов мы сами его и печем, и все в наших руках.

Термина DevOps Engineer, и вообще любой роли, хоть как-то подразумевающей DevOps — просто не существует. Такое название роли имеет столько-же смысла, как и Agile Engineer или Scrum Engineer. Эта выдумка гуляет преимущественно по СНГ, и сложно сказать как именно родилась эта псевдо-роль.

What?

vmware
rackspace
amazon

чуточку Гугла
NY
Chicago
Mountain View

и на закусочку
The Best Jobs in the United States: 2017

как именно родилась эта псевдо-роль

Я как-бы и не отрицал, что на сегодняшний день на рынке такая роль существует, и набрала виральности. Но чего только на рынке не существует. Менее комичным это словосочетание от этого не становится.
Расслабься, я тоже так себя долгое время называл, пока не дорос до понимания. Ничего плохого в самом DevOps Engineer нет (кроме некой комичности игры слов, зная оригинальное значение DevOps и начиная представлять себе по аналогии вакансию на Agile Engineer), плохо размывание философии и идеи ролью из-за путаницы с названием. Когда DevOps и DevOps Engineer существуют параллельно — возникают вот такие вот топики, потому что большинство путается в понятиях, но об этом ниже.
Выше я говорю то, как оно задумывалось, и к чему оно во взрослых компаниях/командах в итоге приходит. Тем не менее, это всего-лишь лычка, и те-же рекрутеры ею активно пользуются для поиска нужного скиллсета, даже во взрослых компаниях. А как известно, вопросы на интервью редко совпадают со скоупом работы ;) Я сам недавно не брезговал хайрить под этим лейблом, а потом уже склонял на темную сторону. Увы, нужного скиллсета, а главное — майндсета, на рынке СНГ пока очень и очень мало, в ход идут все инструменты для поиска.
Ссылки, которые я привел, думаю достаточно авторитетные — офф книга от гугла и чувак считающийся прародителем IaaC и DevOps как такового. Можно нагуглить и больше и глубже, только зачем. Не забываем, что и гугл с амазоном аутсорсят на разные рынки, включая СНГ, и под их зонтиками по части вакансий может появляться все, что угодно, авторства местных самоделов. А вот книга весьма официальна и думаю без сомнений отражает официальную позицию компании.
Конечно, наличие официальных курсов «DevOps Engineer» от Амазона немного портит мою картину, но это результат того, что термин набрал виральности. Некоторые компании уже прекращают бороться, и начинают возглавлять то, что не могут победить. С одной стороны вообще пофиг должно быть, как оно там называется, SRE или DevOps, но устойчивая тенденция на рынке говорит о том, что DevOps Engineer это вредно, потому что за этой ширмой теряется суть философии. Компании без понимания начинают хайрить людей, образуя эти DevOps команды, без понимания сути проблемы начинают автоматизировать ради автоматизации, все что мы получаем — это +1 сайло, и кучу конфликтов в придачу (потому что команда с революционными идеями приходит и ломает всем устоявшийся воркфлоу). Шеринга goals не происходит, из чего и выливаются последствия. Зато модное слово, чо. Вроде в тренде.
По этой причине, я бы предпочел, чтобы термина DevOps Engineer не существовало вовсе, чем каждый раз объяснять всем разницу и важность двух понятий.

Слюшай, дарагой, сам расслабься, да?!
Тоже мне, гуру величины Столлмана нашелся. Это канонично, а это неканонично.
Я как-нибудь сам решу кто такой девопс и существует ли вообще такой зверь в природе.
И уж тем более являюсь ли я сам девопсом или кем-нибудь другим.

А польза от этого топика оказалась огромная. С понедельника начну своих трёх эникеев гонять в хвост и гриву. Выжму из них все соки, но мозгами пользоваться заставлю и дурь о девопс-хренопс выбью. Это то что я упустил в отличии от моих сенсеев. Им в те времена, правда было легче, дури было меньше.

Курсы от Амазона, видите ли портят его картину. Facepalm.

Не курсы портят, а их название. Эти курсы у Амазона зародились несколько раньше, чем зародился термин SRE (когда DevOps был действительно еще не устоявшимся), ну а теперь уже «бренд», менять они не будут. Ну и вообще, амазон может себе позволить многое, будучи одним из основателей и двигателей самой философии.
Не нужно перекручивать, и вообще что-то жареным запахло, сударь, у вас, кажется, подгорает :)
Себя лично я никаким гуру не считаю, это не я все придумал, я лишь ученик, учился у гуру.
А эникеев своих гоняй, гоняй, а то вдруг у них появится свободное время, они узнают что есть better way, и свалят в соседнюю галеру учиться уму-разуму.
Только рынок жаль, нормальные кастомеры с него так и валят, туда где умеют шерить голы и рушить сайло.

"

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

"

Как человек, посвятивший около 8 лет Ораклу — очень хорошо понимаю все вышесказанное.Все течет и меняется, поэтому приходится или принимать новые вызовы, или идти ко дну, третьего, по сути, в нынешнем мире ИТ не дано...

Ой, я не згоден, ну це ті самі роздуми, десь може рік тому у одному з пабліків стався ще один холівар на тему — «нах...й С, С++, Java — коли є PYTHON» ну так і тут. Так — все тече, міняється, та ви хочете сказати що Oracle мертвий ? Ніхто не каже що не треба мінятись, качати скіли далі, це треба і крапка, але не треба кашляти у бік старих технологій які на тому рівні знаходяться коли вже немає що міняти, бо вони вже зайняли своє позицію. Якщо деякі пани не працюють з бекендом дуже круто — то не означаю що воно здохло :) Тому треба як на мене спираючись на свій багатий досвід вивчати нову, аналізувати його, критично аналізувати, та вміти їм користуватись. А девопс — то просто ху...ня по салі :) Хайп для студентів. Люди просто не розуміють нас, так само як і той факт що багато чого для JS було написано на сях, або для python...

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

Лично в моем понимании DevOps позиция, если без всех этих высоких эпитетов о культуре и методологии в работе — это по-прежнему позиция для админов, но несколько в ином формате (работа в команде с разработчиками, облака, автоматизация, мейнтананс инфраструктуры в качестве кода, соотвественно требуются навыки программирования). Ну и понятное дело, что сюда лепят все мыслимые и немыслимые продукты и технологии, отсюда такое разнообразие ролей (DataOps, Big Data DevOps etc)

это по-прежнему позиция для админов

Да, но с навыками разработки. ИМХО.

Просто раздули должность и зарплаты что-бы привлечь кадры — начался голод в свое время.

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

А не смущает тот факт что большинство админов (в моем теперешнем и прошлом окружении) имеют опыт разработки для решения различных задач, хотя бы потому что в институте изучали программирование, ну и сейчас для решения задач педалят кто на чем... Хотя может сейчас админы из разряда разрабов после курсов «я не обязан это знать» :D :D :D

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

имхо не рынок указывает путь, а проект и задачи, пути для запуска проекта. Рынок один, проекты разные, просто сейчас стало модно хаять старое, использовать новое, а при отсутствии аргументов в пользу нового — хамить и гадить...

Ну здесь не стоит забывать про стойкие тенденции, которые идут со стороны клиентов\заказчиков и крупных игроков на рынке. Если ищут американцы именно ДевОпса — значит человек должен полностью соответствовать тем требованиям, которые они предъявляют. И таких запросов сейчас сотни тысяч, как бы они не выглядели по сути

Отписывался вот тут к видосу по поводу термина «DevOps Engineer» и почему это очень даже ок: www.youtube.com/watch?v=iqJjyNXhuOY
А в целом с вектором спича согласен, поддерживаю.

Это имеет огромный смысл в гигантских компаниях, чтобы каждая команда не переизобретала колесо (бранчинг стратегию, релиз менеджмент, CI и CD и так далее) для себя, на чем компания экономит колоссальные деньги.

Почему же огромных? Когда

команду отдельно стоящих SRE

создаёт и поддерживает

бранчинг стратегию, релиз менеджмент, CI и CD и так далее

,
то это очень здорово работает и в компаниях до 100 человек... Недальновидно, конечно, пытаться определить потребность той или иной компании в тех или иных методологиях и практиках опираясь исключительно на её размер....

Чисто технически может и работает. Только дорого, а значит в бизнес модели — не работает. На маленьком масштабе вместо того чтобы убирать оверхед такая команда будет его только создавать, уже не говоря опять же о философии, конкретно о том, что сам факт отдельной команды = плюс одно сайло.
Кроме того, когда нужна отдельная команда SRE, по хорошему нужна она одновременно с SRE внутри продуктовых команд, для шеринга экспертизы и голов. А это еще + $$$. Я видел, как компании пытались сэкономить, например шаря SRE из центральной команды, лишь один раз это более-менее сработало, правда ребята тратили при этом на митинги в неделю по 10 часов минимум (только на стендапы и планнинги, а кроме этого же есть и другие). Хотя, скорее все-таки не работало, потому что кругом-бегом на задачи этой самой «центральной» команды SRE оставалось 10-15% времени, потому деливери платформа и тулсет начали стагнировать, ибо вообщем-то ресурсов хватало только на саппорт этих вещей.

Только дорого, а значит в бизнес модели — не работает

это довольно сложно запустить, но далее сплошной профит.
Когда, например, нужно заменить 6 per-team мониторингов одним универсальным решением — вы сталкиваетесь с вохором проблем, начиная с обсуждения и нахождения компромиссов относительно особых потребностей каждой команды, заканчивая пушбэком лидов команд, которые не очень-то счастливы от потери контроля над частью инфраструктуры, которые они почему-то считают своей. Но когда всё уже сделано, и лиды видят, кто оно таки работает и что теперь у них освободились ресурсы, ранее занятые на поддержке per-team решений — то они уже сами к тебе приходят с предложением «А у нас тут ещё 5 разных CD развёрнуто, давайте и это дело отдадим Core DevOps команде, пусть предложат что-то универсальное». Поэтому возможный провал данной стратегии я могу объяснить только проблемами в DevOps/SRE команде, например — плохая дипломатия или банальный недостаток ресурсов/компетенции. Далее, вариант

шаря SRE из центральной команды

тоже прекрасно работает в том же Box inc, вот только вчера общались с их DevOps директором. Они внедряют SRE в команды разработчиков, и тот параллельно обучает разработчиков создавать поддерживаемый продукт и адаптирует их проект для поддержки единой командой SRE.

Я экспериментировал с per-team SRE, это даёт довольно хорошие преимущества в краткосрочной перспективе (все Ops задачи решаются быстрее, SRE более гибок относительно требований отдельной команды, намного лучше коммуникация итд), но заканчивается плачевно в долгосрочной — каждая команда строит своё королевство, SRE ресурсы используются крайне неэффективно, задачи многократно дублируются, нет единого центра принятия стратегических решений. В итоге — вы имеете по велосипеду в каждой команде, горы технического долга и сильное отставание в технологиях, так как никаких «сдвигов парадигмы» разрозненные SRE сделать не способны

банальный недостаток ресурсов

Ну как-бы об этом и речь. Из моей практики, маленькие компании экономят на спичках, куда там целая команда, косты которой еще и никак не ложатся в капекс, там исключительно опекс выходит. Вам везло с богачами поработать, поздравляю.
Ну и конечно есть исключения, ну например когда конечный продукт компании сам по себе айтишный, какая-нибудь paas например (там на опекс как правило иначе смотрят).

В целом, здесь нет какого-нибудь black/white решения, нет и точной цифры размера, после которой нужен отдельный SRE груп. Цифру 100 в предыдущем сообщении я как-то упустил, только сейчас обратил внимание. Простая зависимость, с ростом размера усиливаются бенефиты и необходимость, а доля оверхеда относительно опекс расходов уменьшается (потому что сам опекс растет с ростом компании), вот и все. Считаю, спор на эту тему нужно заканчивать, потому что похоже на kevah.ru/images/viewpoint_1.jpg — я не берусь сказать 100 абстрактных в ваакуме человек это много или мало. Каждый кейс будет весьма индивидуален, а понятие «большая», «маленькая» и «гигантская» весьма субъективны.

А в целом, многие строки до боли знакомы и откликаются эхом в памяти.

Не зовсім зрозуміло — що є тоді Agile ? Може тоді створити новий образ Agile + CI + CD = DevOps ?

DevOps нічого не описує, бо дуже ефемерне поняття, яке не має стандарту, офіційного статусу тощо. Тому кожен вкладає в нього своє поняття, яке йому зручніше. Ну це моє бачення на цей час,

Agile + CI + CD = DevOps

мені подобається такий опис для DevOps, а технічна сторона — її тут не має сенсу описувати, бо кожен окремий проект — це свій набір інструментів, кроків для білду, тестування, створення оточення, а їх для CI + CD не на дуже багато....

ну я не об’єдную ці поняття, бо доставкою може бути звичайний git pull, а ось інтеграція — це може бути автоматизоване створення тестового оточення, тестування, аналіз коду, після успіху — мерж у потрібний бранч... Інтеграція як на мене більш складний процесс, бо доставка — то вже як все відтестили, перевірили. змержили — виклали нову версію на сервер, та скажемо змінили сімлінк на новий та зробили nginx -s reload

DevOps инженер это не админ, такой человек стоит на пересечении development — QA — operations и отвечает за максимально возможную автоматизацию процессов.

Виходить дуже комічна ситуація: в компанії немає людини яка розуміється на низькорівневих штуках типу мереж, ядра та ОС в цілому. І ще веселіше ситуація із доступом до машин, бо раніше доступ давали компетентним людям, які могли діагностувати проблему із ОС чи залізом, зараз же доступ є тільки у девопса, який тільки й уміє що настроювати дженкінси. :)

Так вот, ITIL — это то же самое, но со стороны заказчика. И позволяет выпилить к монахам туеву хучу лишних «мэнэджеров по лидингу» и прочих «успешных лядей», работая напрямую с Эджайл-командой, по принципам этого самого эджайл — именно за счёт того, что ITIL — это интеграционный слой. Как клей, который проникнет везде, и склеит самое несовместимое в единую конструкцию.

И да, в случае ITIL на стороне заказчика (или даже предоставленного как сервис по аутсорсу) — потребность в QA практически отпадает. Просто потому что на преодоление барьеров и на бюрократию QA тратится больше, чем вероятные убытки от его отсутствия. QA в ITIL тоже есть, но там (и только там) оно оправдывает своё название.

И вот когда вы увидите что QA занимается написанием ТЗ — у вас есть continuous integration. А до тех пор — это штопаный контрацептив с красивой лейбочкой.

Ничего не вечно в индустрии, все как с везде циклично и это уже не первый цикл когда от централизации все расхлопывается до де-централизации и нужны натаскаться руки мастера.
Давеча позвали меня на совещание одно и открыл нам менеджер на душу. Сказал что нужны ему сейчас DevQa, а когда я спросил а подразумевает ли это , что такой фрукт должен под своё решение иэеще и сам инфрастуктцру развернуть, то он сказал что да, что таки нужны:
DevQaOps, звучало классно, как то так «Девкуопс».
Мне понравилось :)

Натаскаться= на все руки мастера

Ага, ко мне подходила рекрутер, спрашивала «нет-ли таких знакомых?».

Но там именно тестирование инфраструкуры.

Тогда это QA, который тестит не апликейшен, а инфраструктуру. Хотя название звучит забавно.

В итоге все катиться к эникещикам и тем вакансиям из двухтысячных- нужен программист со знаниями с++,Pascal, 1с, 3dmax, photoshop, php, joomla, настройка и прокладка сетей — зп 100$.

Спасибо, посмеялся.
Как раз сейчас попал на проект, где для мерджа в мастер ветку паппета нужно заапрувить чендж реквест, и сам этот мердж своим фактом применит чендж сразу ВЕЗДЕ. Зато ITIL, чо.
И сидят, старички, по 16 лет на проекте, обмотались джоб протекшном по самые помидоры, и пернуть нельзя без CAB и тыщи аппрувалов.
Смотрел запись годовой давности (то есть конец 2016), где взрослый дядька, гуру ITIL, кде под фриинебизди вот это все, сидит рассказывает с упоением команде, что оказывается есть Пулл Реквесты, и их можно ревьювать и только потом мерджить. До авто-тестов и по сей день еще не додумались.
The old world dying along with those who are not able to accept the changes, дедуля.

Завдяки прогресу та розвитку технологій бородаті адміни зараз мало кому потрібні — думаю ви самі не будете заперечувати що вартість налаштування та деплою рішень по складності від бложика на вордпресі до серйозно хайлоаду за останні роки значно знизилася, і, думаю ви не будете заперечувати, що це добре.
Зараз до всього є API, адміни потрібні лише тим нещасним які не можуть розгорнути своє рішення у хмарі (банки і тд), і то, можна собі в датацентр поставити PaaS і не паритися.

поминая незлым тихим словом препода, который завалил его курсач за второй курс, так как не понял ассемблерные вставки в коде на Трупо Паскакале

Комплекс невизнаного генія — кому потрібне ваше рішення яке ніхто не розуміє, або яке ви не можете роз’яснити замовнику? Треба вміти домовлятися і не стріляти з гармати по горобцям.

Завдяки прогресу та розвитку технологій бородаті адміни зараз мало кому потрібні — думаю ви самі не будете заперечувати що вартість налаштування та деплою рішень по складності від бложика на вордпресі до серйозно хайлоаду за останні роки значно знизилася, і, думаю ви не будете заперечувати, що це добре.
Зараз до всього є API, адміни потрібні лише тим нещасним які не можуть розгорнути своє рішення у хмарі (банки і тд), і то, можна собі в датацентр поставити PaaS і не паритися.
=======
а ще нещасний автомотiв з нещасними беемве, фольксвагоном та iншими фiятами.

і то, можна собі в датацентр поставити PaaS і не паритися.

йду напишу письмо нiмцям, шо вони тупi

Що за проекції? Я написав що в значній кількості випадків можна тримати рішення у хмарі, а тим хто не може цього зробити в силу законодавчих чи ще якихось обмежень і доводиться тримати свої датацентри і спеціальних людей які їх обслуговують. Тим не менш, навіть у локальний ДЦ зараз ставляться PaaSи, або k8s які значно спрощуюють справу.

глупi немци цього не панимають,
так надо писать ще одне фолоу-ап письмо,
когда ж работать то наконець?

Підіть напишіть, дійсно, може вони не в курсі.

як на мене обмеження одне — адмін у 99% випадків потрібен, то нащо тоді отдавати за EC2 інстанс + RDS + S3 під статику — 2к баксів на місяць, ящко те саме можна зробити на дедіку у ДЦ за ціною від 30 до 500 євро ? Нехай мене заплюють, але всі з ким працюю чи працював — не хотіли витрачати зайвого. Просто э люди які почали працювати зараз. або 2-3-5 років тому, та вони почали працювати відразу з AWS як приклад — то для них незрозуміло нащо той дедік у ДЦ, та вони працюють на людей які витрачають не свої грощі — а інвесторскі, або хазяйскі, та їм пофігу скіки воно кошутє. А є такі що їм потрібно на всіх континентах тримати сервери, та багато чого іншоно, та у таких компаній є грощі, та вони розуміють що не треба брати дедіки у 5-10 ДЦ на різних конинентах бо ж AWS, хоча він і дорогущий, але здебільшого стабільний, та сплачувати треба у одному місці, та все що треба є тут, та вони починають працювати з AWS, та не тому що це хмара, або не потрібен адмін, або ще щось — а тому що так зручніше для їхнього проету, та вони згодні сплачувати більше за це у декілька разів.... ну знову ж — особисте спосереження...

Що ми будете робити коли дедік зламається?

ну у мене на цей випадок
— мониторінг
— резервні дедіки
— превентивні методи

Ну і зустрічне питання — що будете робити коли S3 упаде, або EC2 ? Мені здається те ж саме — буде налаштування аутоскейлів, ресторів, моніторилки та таке інше... Тобто все одно що там що там треба підтримувати інфраструктуру... Різниці лише в тому що залізо AWS сам підтримує, та бере за це $, а дедік якщо зламається — то ДЦ міняє та грошей за це не бере, а налаштування софта на нас, як на клієнті що в ДЦ що на AWS. Що до даунтацмів, вони все одно будуть хоч то AWS хоч Azure, щоч дедік.

І регіонів у вас теж декілька? Ну, не хочу зараз встрягати в срач Cloud vs. bare metal, я значний прихильник першого але і друге має право на життя.

От GitLab думав-думав переходити на bare metal і вреші-решт вирішив що це недоцільно — рекомендую почитати.

S3 упаде

Хотів написати «S3 не падає», а потім згадав про нещодавній outage. Втім, нас він не зачепив, бо ми в іншому реґіоні.

Звісно, завжди є трейдофи, але подвіться наприклад на NetFlix — в них рахунки за AWS просто колосальні, проте вони залишаються там, незважаючи на те що можуть на порядок зменшити операційні витрати. Чому? Тому що людський ресурс дорожчий ніж залізо.

Та тут немає срачу — бо тут як на мене дискусія ... Реально багато чого залежить від проекту, бюджету, менеджменту.... Я починав у 2003 році, коли ще буd редхет 8, а про хмари ще ніхто не чув, бо тоді ще на DSL інтернеті по дозвону багато хто сидів та попрацював з різними технолгіями та проектами, AWS мені дуже подобається, реально дуже, по ньому навчаюсь, але він на цей час не покриває всіх потреб тих — з ким працюю. Для когось він ідеальне рішення, для декого нi. У мене клієнт — у нього інвестори та він попросив мене щоб інфраструктуру не роздували, бо на той час у нього дикі як на мене та фого потреби рахунки були. Щодо адміну у команді, ну не вірю я що проект не для «форум де вагітні мамки» буде працювати без людини яка відповідає за інфрастурктуру, я таких не бачив, якщо не на постійній основі — все одно є людина на парт-тайм яка підкручує гайки.

Людина яка відповідає за інфраструктуру ≠ адімн в традиційному розумінні цього слова, принаймні точно не патчер BSD про якого тут ведеться мова.

Мені подобається термін Site Reliability Engineer/Infrastructure Engineer, він значно точніший, тому що керування сучасною інфраструктурую — це таке саме програмування, тільки не зовсім прикладне.

ну тоді тут питання просто понять, бо я вважаю себе адміном, дехто з клієнтів девопсом, нещодавно тут прочитав що ще є таки цікаві слова як ви написали, але для мене це все одно «адмін» як його не називай. Не вийде налаштувати VPC з приватними мережами,у які доступ по ВПН, якщо не розумієш що воно таке, що таке NAT, та інше... Так балансери, кластери зараз за допомогою інструментів AWS можна зробити, але я не розумію як можна зробити не розуміючи що воно таке, для чого потрібне ? Як на мене не вийде. BSD патчер — тут як приклад того що людина знається на технологіях, якщо у вас виробниче підприємство, та як приклад обмежений доступ (я у такому працював) — то у нас були свої залізки, які патчили, перезбирали ядра та таке інше. Те що зараз багато ИТ конторок використовують хмари — то просто реальний хайп, та під нього нових слів назбирали — треба ж у рахунках розписувати час за що клієнт повивнен сплатити, та щоб пафосно виглядало, бо картинка — наше усе зараз. У мене знайомий адмін йому 40+, теж зараз працює у конторі яка є якимось партнером AWS, так у чому його призначення — у тому, що для таких контор яким не потрібен адмін, вони командою роблять налаштування інфраструктури, пишуть плейбуки для деплою приватних хмар для таких контор, мониторінг, підтримка, вгадайте скільки контори сплачують за такі послуги ? так у контори немаж адміна, так деви самі можуть щось зробити, але первинне налаштування їм хтось робить, та потім пдітримує... ТА він із бородатих ледащих адмінів яким як і мені подобається AWS як красива іграшка, але все одно залізо ми полюбляємо більше :)

От GitLab думав-думав переходити на bare metal і вреші-решт вирішив що це недоцільно — рекомендую почитати.

А от Гугл чомусь не переходить до Amazon :)
Так, приклад надмірно маргінальний. Але показує, що межа таки десь є.

на NetFlix — в них рахунки за AWS просто колосальні, проте вони залишаються там, незважаючи на те що можуть на порядок зменшити операційні витрати.

На порядок — ой навряд чи. В 3 рази — це максимум. А чому Ви вважаєте, що вони не отримали від Amazon знижку відсотків так 60 (якраз десь до ціни повної підтримки своїми силами)? Вони можуть сказати «якщо не погодитесь, ми підемо до Гугла або MS на таку ж знижку», і це типова поведінка у таких випадках. Я готовий віддати бутиль чогось 40градусного за те, що саме так і було ;)

А от Гугл чомусь не переходить до Amazon :)

Тому що вреші додумались зробити GCE. Якби зробили це на 10 років раніше то зараз не були би в хвості ринку.

А чому Ви вважаєте, що вони не отримали від Amazon знижку відсотків так 60

Я вважаю що вони мають серйозну знижку як один з найбільших клієнтів, але навіть з нею при переїзді на bare metal можна зекономити.
Втім вони йдуть по зворотньому шляху, нещодавно весь білінг з власного датацентру на ораклі перемістіли на аврору.

Ви би краще згадали Dropbox які втомилився від мільонних рахунків за S3 і за рік заінженерили власний сторедж.

Тому що вреші додумались зробити GCE.

Це не відповідь аж ніяк.

Я вважаю що вони мають серйозну знижку як один з найбільших клієнтів, але навіть з нею при переїзді на bare metal можна зекономити.

Не бачу підстав для такого висновку. Скоріше матимуть більші затрати на персоналі.

Ви би краще згадали Dropbox які втомилився від мільонних рахунків за S3 і за рік заінженерили власний сторедж.

І чим це «краще»? Так, був і такий випадок. Там, наскільки памʼятаю, сама організація S3 була неоптимальна для них. Це інша проблема.

Не розумію про що ми сперечаємося, згортаюсь.

Якщо про межу коли треба переїжджати на bare metal — то вона у кожного своя. Комусь прикольно адмінити свій ДЦ, комусь — ні.

На мою думку, для сучасних стартапів/продуктів bare metal повинен розглядатися коли це має реально серйозні переваги понад хмарою. Тоді можна вже й спеціалістів по tcp/ip найняти і збудувати сарай класу A+ з кондиціонерами, двома незалежними лініями живлення та дизельними генераторами. А поки воно не треба — і розробник який не сачкував заняття по мережам розбереться з налаштуваннями VPC.

Швидко _тимчасово_ підійму інстанс в AWS :)

що вартість налаштування та деплою рішень по складності від бложика на вордпресі до

... бложика на Вордпрессе + MVP стартапчика.
Все остальное требует достаточно специфичных знаний и опыта. И всегда будет требовать.

можна собі в датацентр поставити PaaS і не паритися.

Ага. И обслуживать оно будет само себя, конечно. ;)

бородаті адміни зараз мало кому потрібні

- роздум з тієї ж теми «perl — мертвий»....

вартість налаштування та деплою рішень по складності від бложика на вордпресі до серйозно хайлоаду за останні роки значно знизилася

Ох не знаю, не знаю, може у вас проекти були всі на вордпресі та джумлі, але я зараз наприклад працюю з проектом, де я та декілька программістів працюють над деплоєм, автоматизацією, та він значно, на багато значно складніша від вордпреса, хоча б тому що стек технологій у проекту не «php + mysql», та лише підготовка для unit тестів хоча і автоматизована — та просто запуск підготовки йде хвилин 10, а потім ще тести unit + bcc працюють десь годину. Або коли прийшов у проект, десь місяці два робили реструктуризацію, яка привела до економії лише за рахунок зниження витрат на інфраструктуру десь 15к$ на рік, бо у команді не було адміна, та хлопці такой ху...ні наробили, що керівництво вирішило взяти адміна (DevOps по їхньому). Та я розумію хлопців, вони розробники — як один мені сказав — чого я повинен витрачати час на інфраструктуру, якщо для цього є адміни ? Та він як на мене вірно сказав, бо кожен повинен займатись своєю справою.

адміни потрібні лише тим нещасним які не можуть розгорнути своє рішення у хмарі

адміни потрібні тим, у кого проект виходить за рамки вордпресу, або якщо у команді э девелопери які знаються на мережевих технологіях та таке інше що звичайно є скілами адмінів. Або якщо грошей настільки багато, та зовсім не стає питання економії — але я про таке тіки чув, особисто бачити не доводилось, тут як приклад у тепершнього клієнта проект, та він мені каже, у нашого партнера на його інфраструктуру виходить на місяць блихко 10к$, при трафіку 40 млн на добу, а у нас на тому самому трафіку 400 евро, ось вам і різниця між хмарами AWS, та дедіками у хетзнері.

а у нас на тому самому трафіку 400 евро, ось вам і різниця між хмарами AWS, та дедіками у хетзнері.

Ви платите гроші адмінам які менеджать дедіки у хетцнері, тому різниця не така серйозна.

Проте я погоджусь що здуру можна і ногу відстрілити витратити всі гроші підняті на раунді А на амазон.

може у вас проекти були всі на вордпресі та джумл

Ні, в мене складні проекти (з юніт тестами і автодеплоєм бгг), суть в тому що зараз не треба знати, що таке iptables тому що є секуріті групи, не треба знати що таке chef/puppet тому що є AWS, Docker і контейнері оркестратори, практично не треба знати що таке nginx/haproxy тому що є лоад балансери і так далі.

або якщо у команді э девелопери які знаються на мережевих технологіях та таке інше що звичайно є скілами адмінів

А от тут в мене думка що всі девелопери повинні знати як деплоїться та працює їх рішення, якщо не на найнижчому рівні, то по верхам, щоб розуміти де проблема якщо в тебе один сервіс другий не бачить або чому твій сайт не відкривається по www.

Під «не треба знати» я розумію не треба знати тонкі нюанси роботи. Самі концепти і базові конфігурації звісно треба розуміти.

Ви платите гроші адмінам які менеджать дедіки у хетцнері, тому різниця не така серйозна.

Еммм, 400 евро сервер, 2000 адмін, 2500$ проти 10000$ — як на мене велика різниця.

що таке iptables тому що є секуріті групи, не треба знати що таке chef/puppet тому що є AWS, Docker і контейнері оркестратори, практично не треба знати що таке nginx/haproxy тому що є лоад балансери і так далі.

Еммм, а якщо до атак на стек TCP/ip ? А якщо до route53 — це ж треба дещо розумітись в мережах, роутингу та таке інше. chef/puppet не потрібен тому що э AWS та докер, ви серйозно ? Ну ось у мене у одного клієнта інфраструктура на AWS і що ? Для деплоя та підготовки тестового оточення — ansible + bash, бо треба з продакшена деякі данні брати, не усі, а частково, а э ще данні у ElasticSearch котрі те ж треба для тестового оточення, а ще э структура данних яка повинна будти синхронизована з mysql... Можу багато про теперешню систему клієнта розповідати, та вся дев команда з величезною радістю це все зкинула на мене — бо тепер їм не треба займатись цим усім, бо система дуже та дуже волатильна.

А от тут в мене думка що всі девелопери повинні знати як деплоїться та працює їх рішення, якщо не на найнижчому рівні, то по верхам, щоб розуміти де проблема якщо в тебе один сервіс другий не бачить або чому твій сайт не відкривається по www.

Ці слова та девам у вуха, мало хто розуміє як воно працює, та ще менше хоче з’ясовувати, за останній рік було на проекті 4 фронта яких звільнили та у всіх була козирна фраза «я фронтенд — я не обязан это знать», бляяя як мене це вибішувало, коли є інструкція, ж документація по проекту, треба прочитати, та зробити як написано, а люди не вміють... Ну то таке — особисте...

Під «не треба знати» я розумію не треба знати тонкі нюанси роботи. Самі концепти і базові конфігурації звісно треба розуміти.

 ну такий підхід підійде лише для невеликого та простого проекту, бо щось складне — треба знати тонкощі... Ну це таке — імхо...

bash

Можна запхати в launch configuration :) Або взагалі зварити свій AMI і користуватися ним.

а э ще данні у ElasticSearch котрі те ж треба для тестового оточення, а ще э структура данних яка повинна будти синхронизована з mysql

SQS, SNS, Lambda, стріми всі діла. Взагалі не розумію до чого тут адміни, якщо це частина аплікейшена.

можна все, ну а щоб зрозуміти — треба знати проект, його потреби та властивості. Хлопці те ж думали що амазон їм допоможе, але ні. Я тому і кажу — що багато чого залежить від проекту, та вордпресс деплоїти — не можна порівнювати з чимось більш складним. Тут знаєте як — один чувак на курсах пітона каже — нашо той баш, перл, э пітон, сучасні адміни повинні тільки його використовувати, от скажіть мені чим той баш чи перл може стати кращим за пітон, є пітон — треба його використовувти (просто чувак не зтикався з inline парсингом логів, або замінами у конфігах), ото так і тут — якщо не було ситуацій які б дали розуміння принциповой різниці між хмарами, дедіками та до чого тут адміни — то важко пояснити. (Про пітон то не задля холівару — лише як приклад).

Хлопці те ж думали що амазон їм допоможе, але ні.

Ну так, я ж кажу

здуру можна і ногу відстрілити витратити всі гроші підняті на раунді А на амазон.

Я думаю що якби вони знали-розуміли що там і як то можливо би і зробили все нормально.

Не треба сприймати AWS як ще один VPS-провайдер і все буде круто.

Так вони розуміють, деякий час зпочатку головний мені показував що у них та як, та чому саме так. AWS я сприймаю саме таким — чим він є, бо він є віртуальною платформою, з тими ж самим VPS на базі HWM, та багато чим іншим, та він не є панацеєю, як одна людина нещодавно цікаво як на мене сказав «зараз массовий хайп щодо технолгій» та він правий, бо багато хто бере та використовує те — що у тренді, а не те що краще для проекту...

Для мене основний цимес AWS не в EС2 інстансах, а в всьому що навколо — ELB, ECS, DynamoDB, SQS/SNS, S3, VPC і всьому іншому + API до цього. Якщо з використовувати тільки EC2 то краще вже сидіти в DO або де там — в цих теж є апі.

Упереджуючи питання — можна звісно тримати віртуалки на DO і користуватися сервісами амазона, але воно не завжди зручно і сек’юрно.

Ці слова та девам у вуха, мало хто розуміє як воно працює, та ще менше хоче з’ясовувати, за останній рік було на проекті 4 фронта яких звільнили та у всіх була козирна фраза „я фронтенд — я не обязан это знать”, бляяя як мене це вибішувало, коли є інструкція, ж документація по проекту, треба прочитати, та зробити як написано, а люди не вміють...

Вирішується дуже просто:

I’m a big fan of all developers being on-call, at least to some degree. You simply cannot teach people to build robust and reliable systems without feeling the pain themselves. You cannot talk about concepts such as self-healing systems or introducing failures by design without getting the people who build it to wake up at night and understand why it matters. Don’t outsource this skill too quickly.

jvns.ca/...​18/operate-your-software

— роздум з тієї ж теми «perl — мертвий»....

Ну в общем так и есть — с него очень активно уползают. И я поддерживаю — сам уползал — несмотря на его отдельные заметные преимущества. Вон недавно booking шумно сполз на яву(!)
В чём-то грустно — уходит эпоха.

Та я розумію хлопців, вони розробники — як один мені сказав — чого я повинен витрачати час на інфраструктуру, якщо для цього є адміни ? Та він як на мене вірно сказав, бо кожен повинен займатись своєю справою.

Это, к тому же, виды деятельности, которые сложно совмещать в одном мозгу при полной нагрузке.

у нашого партнера на його інфраструктуру виходить на місяць блихко 10к$, при трафіку 40 млн на добу, а у нас на тому самому трафіку 400 евро, ось вам і різниця між хмарами AWS, та дедіками у хетзнері.

25 раз — сурово, я не предполагал больше 3. За счёт чего так получается?

25 раз — сурово, я не предполагал больше 3. За счёт чего так получается?

Я не знаю який у них софт, та яка інфраструктура, але t2.2xlarge EC2 коштує без HDD щонайменше 280 долларів, дедік один такого плана але на AMD я беру за 35 євро, у мене 4 дедіка та бекапні сервери і адмінка , FailOverIP. На нашому трафіку я якось рахував тіки за Redis платили б близько 1000, у нас ще mysql + mongodb, тобто я так порахувув із знайомим AWSником — якщо робити хмарно — десь близько 5-7к$ на місяць, 4 EC2 як фронти через ELB, mysql, mongodb, redis — у хмарі, ще EC2 для статистики, та адмінки, тобто у мене 10 серверів зараз вийде 350-400 євро, ті самі у AWS 2800, + бази (десь близько 2к на місячь), + бекапи(S3 тут важко порахувати, але думаю щось близько 100-200 долларів) от і виходить своє перенести 5к щонайменше без дисків до інстансів ... А що там у партнерів — не знаю, тому не берусь рахувати, але дивлячись на те що у мене виходить, то все цілком логічно — багато чого залежить від адміна, програміста — ми свою систему зробили не відразу, з початку була покупна — та їй ще більше потрібно було ресурсів, потім коли покупна вже задовбала усіх — я з програмістом клієнта забабахли свою...Так і живемо....

це дуже, та дуже різні ситуації, якщо ОДИН проект розростається на 100-200-300 серверів, я б все одно не переходив на хмари, тому що
— Багато ДЦ беруть на колокейшин сервери
— Адміни ДЦ можуть замінити диск якщо він полетів, та якщо треба багато іншого
— OpenStack дозволяє обьєданти сервери, та працювати зі своєю хмарою та має особисте API.

Та якщо у тебе багато проектів які розташовані на 100-200-300 серверах, коли ти не в змозі зробити єдину структуру, бо воно все різне, та ти працюєш з дедиками бо вони виходять дешевше, та потужностей більше.

Я можу ще багато прикладів навести спираючись на особистий досвід, але розумію що комусь простіше просто зробити у AWS свою інфраструктуру, тому що..... (тут багато букв чому...) :)
Я із не дуже старих адмінів котрі пристосувались до сучасних технологій та працюють з проектами спираючись на старий досвід, та на сучасні технології.Та перед тим як ввести в роботу якусь чергову новую ху....ю під соусом «сучасні технології» запитаю «навіщо воно, та що воно зробить нам краще, або гірше?» Бо чим більш різноманітна інфраструктура — тим складніше її підтримувати, особливо коли у тебе на одну пару рук 100+ серверів. На цей час такий підхід — зекономив багато бабла клієнтам, на жаль % від зекономленого не дають у вигляді премії :(

Діалог перейшов до дискусії :)
Це ваше особисте бачення ситуації, у багатьох людей воно інше, бо міряють іншими мірами.

Щодо заліза та його підтримки — я вище писав, візьміть та порахуйте. Тут немає чого обговорювати — бо проекти різні та завдання у них різні. Адміни ДЦ відстежують статус вашого сервера, та якщо ви десь загуляли та не зреагували на алерт — то вам подзвонять, особисто у мене так було.
У чому питання щодо опенстек ? У амазоні — зарегатись та просто замовити EC2 це не те саме що засетапати свій клауд із своїми політиками безпеки, налаштуваннями так таке інше. Тому і опенстек — все одно треба підтримувати, налаштовувати.... Адміна з прямими руками — теж треба знайти, на AWS або стек те ж ще пошукати треба, бо «anykey» адміни для фвс або стека зараз теж пішли в маси. Тому це зовсім не аргумент. Опенстек дає як на мене набагато більше свободи та можливостей у купі з збереженням фінансів чим AWS. Ще раз скажу — підтримувати треба ВСЕ. Хмари хмарами, дедіки дедіками, все залежить від потреб проекту.
Трафік зросте у двічи — то й що ? У мене був стрибок з 4 лямів на добу до 80 лямів, на дедіках — та нічого, всі живі здорові, то ще круто якщо за місяц попереджують, а не за годину чи постфактум, зараз 25-40 на добу, всі живі здорові, тому що можна без контракту взяти ще одну залізяку на місяц — два, витратити на це 100 євро а не 500 чи ще більше. А якщо зовсім складна ситуація я використовую скалавей, дешево та сердито як то кажуть, на то я і адмін, щоб вирішувати питання з інфраструктурою, та вкладатись у бюджет, відстежувати те — як працює софт, та чому стає потреба у збільшенні потужності, а не бездумно роздувати бюджет та інфраструктуру, бачив і так, та доводилось зменшувати інфраструктуру, бо у когось рукожопість була, або індуси базу проектували. Мені це подобається — бо я можу проводити на залізі тести для закривання особистих питань таких як «nignx vs apache», «perl vs python», чому редіс — це лайно.... :) Ну то — особисте, клієнт зазвичай і не знає що ми з його прогером балуємось :)

Ага ага — швидше, простіше :) Я не бачу різницю у сетапі 50 дедіків одночасно та 50 інстансів за допомогою ansible, або Cloudformation — хоча останній крута штука беззаперечно :). Чесно, принципової різниці не бачу — бо все працює на базі інструкцій, які терба через веб завантажити, або надати лінк для завантаження, або поросто команду запустити. Є тільки питання — що залізо може зламатись, та й усе, все інше — особисті пристрасті, та бабло.

managed сервисов, которые предлагает AWS

Ще раз — візьміть калькулятор та почніть рахувати, я не знаю з якими проектами працюєте ви, та чиє там бабло, але те з чим працюю я — є потреба рахувати, бо бабло не чиєсь, а своє, проекти не чиїсь — а свої. Та сплачувати у 10-20 разів більше за ОДИН сервер (інстанс) у мене клієнт не хоче, а аргументів чому треба стільки переплачувати, та чому преповзати у хмари — у мене немає...

Хоча чому сперечатись — мені подобається AWS, але він дуже багато коштує, тому як альтернатива — мозок та дедіки :)

На таких размерах проще приготовить опенстек или купить поприетарный движок для клауда.
И будет апи и вся фигня.

В чём-то грустно — уходит эпоха.

так, дуже сумно, це напевно мені так само сумно, як колись фідошнікам — коли интернет з’явився.... Але все одно для мене perl — живий :) Краще за нього логи ніхто не хаває...

Просто вброс на вентилятор. Если вы такой крутой юникс гуру — устраивайтесь на работу в Амазон, им всегда нужны спецы с хорошим опытом «низкоуровневого» администрирования. Тогда как в нашем аутсорсе, где заказчику нужен прогресс на уровне архитектуры приложений (хайлоад, микросервисы, облака, ci/cd, вот это вот все) ваше умение «руками смонтировать zfs под линух ядро имея только ссх» как то особо не нужно. Если хочешь денег нужно не строить из себя гуру, а развиваться и отвечать требованиям рынка.

Вычеркивайте хайлоад.
В большинстве наших местных контор и проектов им и не пахнет, а где пахнет — там с головой дружат.

Но не знать современные тулзы это таки стыдно.
Рынку надо отвечать, но тащить в пректы все подряд ради моды не нужно.

Если заказчик — новомодный стартап сорвавший инвестиций, то им зачастую в архитектуру надо все что модное в интернете моргает реализовать нужно. Иногда когда видишь спецификацию по проекту думаешь что они просто все аббревиатуры которые знали перечислили. :)) И там будет и контейнеризация и оркестрация и автобалансировка нод по метрикам нагрузки. И не важно, что у стартапа то клиентов ещё пару штук, главное на тестах менеджменту показать что работает))

контейнеризация и оркестрация и автобалансировка

Это норм как раз.
Если это сделано с умом.
Но вот выбрать оптимальные реализации «на вырост» могут далеко не все.

Если вместо того что бы ныть по форумам — научиться этими самыми

модное в интернете моргает

грамотно пользоваться, то

контейнеризация и оркестрация и автобалансировка нод по метрикам нагрузки.

без проблем закладывается в дизайн инфраструктуры и далее вы не паритесь. Зато когда вдруг стартап выстрелит — лучше писать статьи о том какой ты офигенный и как ты скейлишься в бложике cloudplatform.googleblog.com/...​life-on-Google-Cloud.html, чем письма с извинениями клиентам, мол наш старовер-админ не предвидел что наш
дурацкий стартап взлетит, приходите в следующий раз

Ну и вообще, при современном дичайшем спросе на толковых SRE — подобные Элис с её конторой забываются в процессе составления календаря собеседований на завтра. Если же желающих собеседовать нет — значит самооценка аффтара не соответсвует реалиям

А вообще да, получается что хайлоад обычно игрушечный какой-то

Відчувається, що Пєтровіч занадто близько спілкується з Еліс, яка явно ± вдвічі молодша від нього, раз знає інтимні подробиці її перших поїздок на бехах.
Можу Пєтровичу порадити декілька речей:
— Якщо вам супер потрібне місце в конторі «Рога і Копита», де Еліс є рекрутером і ви на 140% впевнені, що відповідаєте вакансії і взагалі, що з вашою участю контора вийде на першу космічну швидкість, то можна написати інакшому рекрутеру або навіть місцевому техліду/СЕО/просто місцевий батя і повідомити, що шукаєте роботу і ось саме це місце ваше. Якщо ж її відмова просто заділа ваше ЧСВ і у вас нема планів на ту контору, забийте, бережіть сили і нерви.
— Поменше сублімувати на Еліс, бо, очевидно, вам потрібно різного в житті.

Все набагато простіше. ЧСВ задіте тим, що світ прогресує та змінюється досить швидко, а зона комфорту вона така, не всі здатні подолати вихід з неї. Звідси й образи на весь світ, що я такий-сякий, бородатий та жирний дядько в розтягненому светрі, а якась дрищява малолєтка в окулярах знає та вміє більше мене)))

входний фильтр для резюме

эх.... о наболевшем.... где те старые добрые времена когда ценился мозг....

че за высер?! ваще ни о чем...

Ни о чем. Есть конечно приколы разные, но опыт админа в именно девопс методиках не всегда и нужен.

а дайте линк на «девопс методу» ? А то чет свиста много вокруг слова «девопс» а толку мало, потому что каждый как хочет — так и интерпретирует это слово, понятние... Ну и

опыт админа в именно девопс методиках не всегда и нужен

ага а потом лезут тупые вопросы типа «я фронтент — я не обязан знать что такое mysql и как распаковать дамп себе локально», или «я ПРОГРАММИСТ я должен кодить, ты мне сделай что бы по вызову mail() отправлялась почта, я не хочу знать как оно работает»... А по итогу что первый что второй пример живут по озвученному вами принципу, и творят такую ху...ту, что не натянешь, с таким подходом проекты превращаются в тонны говнокода, инфраструктура в хлам стоящий бешенного бабла...

Чето бомбит так нехило, даже читать до конца не стал.
По поводу того «кто как интерпретирует» это именно их проблемы, методология она одна и какбэ гугл никто не отменял. Захотите, найдете, боль в нижней части спины описывать не нужно.

ну да — зачем читать до конца, если себя из первых строк узнал... гуглом пользоваться я таки умею, а вот методологии такой нет, есть тонны говна которые выдаются за методологию, есть

«кто как интерпретирует» это именно их проблемы

 — ибо если есть методология — ее никак не интерпретируешь, есть стандарты которые сложно извернуть по другому, ну и есть говно которое каждый как хочет интерпретирует, ну и лычку типа модную себе повесить — «смотрите, завидуйте — я девопс, а не какой нибудь админка» ....

пффф) расслабьтесь, я админ, который сейчас работает девопс инженером :D :D :D
Всего хорошего, короче

обосрался, сьехал и убежал.... Кросавчег... Удачи.

главное не потеряй скрин, лет через 10-20

я админ

" может вырасти и дойдет о чем тут писалось :)

бош, ну попоболь так попоболь)))
Тут прекрасно понятно о чем написано)) И твоя бомбежка зада, судя по должности, это подтверждает :) одминчеги, которые застряли во времени и не собираются усваивать новые методологии, технологии и расширять свои знания, обычно бомбят))))) тут все предельно ясно до тупизма) Но не надо всех обвинять вокруг в том, что они тупые, если сам особо развиваться не спешишь ;-)

у кого что болит — тот о том и говорит, ну это так — из личного опыта, я говорю о наболевшем — тупизне среди именующих себя разработчиками и девопсами вроде вас, вы говорите про

попоболь

, если там боль — сходите к врачу, о ваших проблемах в той области мне не интересно знать. Ну и

новые методологии

 — вы так и не дали мне тупому. застрявшему во времени и не сменившему лычку одминчегу линк — на те самые методологии, что собственно подтверждает статус галимого балабола и троля.

ага, ага) Прям как про голубя — не спорьте сним, а то на$рет и с гордостью улетит))) Это про Вас, ибо эти детские «ты дурак — сам дурак» просто смешат)))
Я обычно не кормлю тролей и не кидаю никаких ссылок, потому что всю инфу ищу сам, а если человек не в состоянии погуглить и понять очевидное, то пусть 3аdра4ивается дальше на одном месте :)

Троль, ты начал хамить и дерзить, именно так и ведут себя тролли, ну а если нет — то почему включаешь мороз ? Или вас на ваших курсах вайти-вайти не научили культурному общению и отвечать за слова ? Похоже нет, ляпнул вы...ер, а дальше можно просто попи...ть — сказать та больше нечего, ну или побузить, все равно сижу в стольном граде — за слова отвечать не обязательно, да говноOps ? Или все же поможешь бедному лоху ссылочкой на курсы халатников или подобные где расскажут про эту методу ?

дура4ок выглядит так) А еще обычный старый и ленивый одмин, обиженный на прогресс :)
Удачи, любви и терпения! А, еще, денег нет, но вы держитесь там)))

Ну как минимум сатус

говноOps

подтвержден, уже с одним диагнозом определились, ну а то что вы сея охарактеризовали себя как

обычный старый и ленивый одмин, обиженный на прогресс

это уже пол дела, так как признание наличия болезни уже пол дела — осталось поучится, наработать практики и жизнь наладится, может в институт сходите хотя бы на заочный... Кстати то что денег нет — сожалею, так обычно бывает у галерных рабов, их держат на печеньках да смузи, а те радуются что у них красивая лычка, похеру что баран — главное теперь можно выебн...ться перед окружающими, да говноOps ?

пеши, пеши ес4о) За что «люблю» ДОУ, это за то, что без огнетушителя пукана дают «вы$раться» всем, кому попало)

говноOps — ты еще тут ? Беги читай — изучай новые методологии, технологии, может денег заработаешь, а то не хорошо как то — лычка модная, а

денег нет

Хорошо бы Вам таким заняться, а то совсем поток коричневого «сознания» )

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

а вот хамить — это айяяй, признак школоты и тупости

ох, неужели пол леса должно было здохнуть, чтобы прийти к такому ВАЖНМОУ выводу?

ну так это к вам вопрос, а не ко мне, ибо из вас полезло Г на простой вопрос дать линк на озвученную вами методу и простой пример из личной практики — к чему приводит не знание смежных областей.

Ну это я тролем и прочими «прелестями» начал кидаться)))))
Я написал простой совет — гугл. Универсальной линки не существует.

но только с тем кто работал и со старым и с новым, а не с тем что считает что можно что то деплоить без админского опыта или строить инфраструктуру без этого же опыта

ДА ЛАААДДННООО! У вас же априори Элис это тупая девочка, которая ничего не знает и не умеет, все без разбору)))

А по вашему это нормально — отсеять человека потому что он не знает или не достаточно знает одну технологию из тысяч ? Для меня нет, потому как все проекты где я работал — нанимались профи и их на работу брали другие профи. которым пох...й было на то как человек говорит — громко или тихо, высокий он или нет, бородатый или лысый — не пох было в состоянии человек сам решить проблему, не паря мозг 10 окружающим коллегам, или в состоянии не зная технологии вникнуться в нее и изчуть самостоятельно имея документацию или может даже не полную документацию, то есть берут на работу мозги, а не внешний вид, а ваша Элис делает подбор именно по внешним принципам, от того в среде профи ее считают тупой, так как она лезет анализировать то — в чем не разбирается. Я вам больше скажу — мега профи который знает вся и всех и везде, с кучей опыта — придя в большой и среьезный проект, вынужден будет потратить время на изучения того что тут есть, как работает и почему имеет именно такую структуру.

Нет, не нормально. Я нигде не сказал что это нормально. Просто всех равнять под одну гребенку — моветон! С такими вот Элис нужно прощаться сразу и идти к профессионалам, где заметят опыт или знания, ну или вообще рассмотрят потенциально успешного кандидата, а не да, кол-во строчек в его резюме или внешний вид.
Просто пост это крик души человека, у которого задето ЧСВ, а все должно быть проще — такая контора должна быть послана и жизнь должна продолжаться.
Вот я и пишу, что пост ну тупо не о чем, зачем было тратить время на соячинение этих строк, чтобы всем рассказать про свое задетое ЧСВ? Что-то поменяется в жизни у этого человека или у Элис? Ну епт, детский сад.

Вот я и пишу, что пост ну тупо не о чем, зачем было тратить время на соячинение этих строк, чтобы всем рассказать про свое задетое ЧСВ?

Ну, например, чтобы какая-нибудь Хильда поняла, что не надо быть такой Элис.
И даже если из 10 Хильд поймёт одна — возможно, это стоило поста.

В принципе, оно ровно для этого и делается. Только горит у каждого своё.

Но видимо да, у кого что горит, 100% ))

Всех не могу ровнять — я сужу только о том с чем работал, кем работал, сталкивался и скажу что этот крик — просто хоть как то озвучить тот пиз...ц с которым приходится сталкиваться. Если у вам не приходилось с таким сталкиваться — я вам завидую. Мне приходилось побывать в конторах на собеседованиях — я как то писал уже об этом, и уходил оху...вшим оттуда, от подхода, от звонков типа «Дмитрий — а вы можете ЗП скинуть в два раза и мы вас возьмем? », были и удаленные собеседования когда тебе находу придумывают задачу, ты отвечешь, а человек на ходу дальше сочиняет — я после второго раза такой ху...ни, если и иду или созаваниваюсь пообщаться — такие диалоги сразу сразаю, ибо нех...й за счет меня подымать свое ЧСВ, когда то то же жаловался и психовал — а потом почитал как то статью о том что есть гандоны которые по своим каким то причинам себя так ведут, поступают. Так и тут — автору наболело, может попался на таких уродов, может еще что то, вот и написал, я его понимаю, поддерживаю, кто то еще понимает, кто то нет. Опыт такая штука — что сразу весь, что нужно не получаешь, его нарабатываешь — в том числе и опыт общения с мудаками в том числе и при приеме на работу.

Открою Вам секрет — такое есть АБСОЛЮТНО у всех, причем страдают как нормальные конторы от «тупых» кандидатов, так и опытные и грамотные кандидаты от «оху***вших» контор.
То, что автору наболело, понятно, но он это подал под другим соком, а соком того, что девопс это тупые малолетки, ничего не поинмающие, а старые дядьки админы это сила, которых надо брать только из-за их опыта и возраста возможно.
А его боль по поводу девочки — ну блин зачем мне это читать на ресурсе про айти? Для этого есть е6аное ресурс

ну подача материала — тут надо уметь, не всем дано, а раз можно написать — пишут все — как умеют. Ну а что до девопса — понятие то новое, реально свеженькое, пару лет отроду, и у него ни описания ни стандарта, ни документации. Трактуй как хочешь, отсюда и отношение к этой специализации — когда читаешь «надо девопс» и перечисляют то что делает админ. Приезжаешь на одну, вторую, третью конференцию посвященную девопс — а там ответа нет, смотришь вебинар — а там ответа нет, есть еще и обсираение старого без аргументации, попытки выяснить чем А лучше Б, ответа нет, только Б это новое, а значит лучше, на вопрос работали ли с А в равных условиях — нет не работали, зато вот на хабре писали что тестили и Б лучше... Мрак... Для меня наболевшее я даже скрывать не буду, причем во многих смыслах.. Что до ебаного — однобокая подача материала, напрягает, в коментах куча срача, мата и дерьма — какое то время читал, потом надоело, думаю так и у многих.

Такое. Для критики и наболевшем как раз е6аное и сделано. То, что там много г0вна да, я потому его и не читаю, особо не хотел бы видеть сопли здесь.
То, что Вы написали да, это давно известная проблема, потому что многие подхватили волну хайпа и не понимают что такое девопс методология и для чего она призвана. ошибочно восприняли что это новый ультрамодный админ и все радостно подхватили. Но это не значит что методология сырая и неправильная, она давно возникла забугром и есть достаточно много документации, описывающей все процессы и вообще зачем возникла.

Имхо ебаное — для пиара, черного. Я б про многие вещи, конторы, приколы не узнал — не прочитай об этом там. Методология девопс имхо — я ее вообще не вижу. Так как то — что позиционируют девопсу — описано в аджаил манифесте, а инструменты для автоматизации аджаил — пихают в требования под девопса. В итоге мракобесие и черти что. Отсюда я все равно попрошу вас пожалуйста поделится своими источниками информации, так как понимаю что я все же могу ошибаться, чего то не понимать. Но во всех вакансиях по девопс — одна и та же песня= работа с облаками, автоматизация, настройка чего то там еще. Для меня все сводится к тому что девопс, это просто админк который может настроить конторе, команде — аджаил процесс. Но — это имхо, потому и хочу почитать, возможно что то новое узнаю :)

Практически правильно, но это в украинских реалиях больше. Посмотрите как построены процессы там, в крменвиевой, например. За источники так с хоуд не скажу, я обычно читаю рекомендованные ссылки. когда где-то в чатах/форумах присылают, ну или на флипборде у меня подписка по тегу devops и т.п.
Основная идея девопс это не столько облако, сколько правильная взаимосвязь между девелопментом и всем оперейшном, который необходим для девелопмент сайкла — отсюда разворачивание инфраструктуры под девелопмент (админская часть) и автоматизация вместе с оперативным устранением проблем в билдах или тому подобное (тут уже больше знания девелопмента). Я конечно тоже не гуру и могу ошибаться, либо не точно высказаться, но сейчас оно уже тоже все меняется, в сравнении с тем, что было лет 7 назад. Сейчас уже часто про SRE говорят.

Сейчас уже часто про SRE говорят.

Мля и вот как спокойно реагировать, когда то еще сырое, это не допилили, зато захуя..ли новое.... Мне можно сказать за почти 15 лет уже реально задолбало пониманть одно за другим, хотя то админство что было в 2003 или 2006 и даже в 2009 когда ушел фрилансить — мне реально больше нравилось чем то что сейчас, последние 3 года я тупо оху...ваю... Да изучаешь, да применяешь — но все равно не перестаешь оху...вать от «нового» насколько оно «неповторимое» .... В любом случае если надо будет — буду учить, изучать, так как админство — все мое, как его не называй. Ну а вас попрошу на меня не серчать, я не со зла пофыркал :)

Принято :) проехато))
Ну, новое не всегда лучшее, но и со старым тоже нельзя всю жизнь быть)
Тут больше зависит от желания, на чем будет проще и лучше, то надо и использовать.

Есть книжка, которую рекомендуют, но так был очень большой холивар по поводу нее среди девопс тусы:
books.google.com.ua/...​esc=y#v=onepage&q&f=false

прочитал еще прошлым летом :) Мне не понравилось, ибо в ней описано про плохое управление крупной компанией. Я не спец в управлении, но другого обьяснения не вижу.

Честно, я еще не читал... Много чего нужно прочитать, но тупо на все не хватает времени...
Кстати, в слак канале часто обмениваются опытом, так же и присутствует много админов, которые девопсят:
ukrops.slack.com

Почитать можно — так как написана не техническим языком, а как художественная литература. Я читал в качестве чтива перед сном — расслабить мозг. За линк спс

Да, про нее так и говорили

А по вашему это нормально — отсеять человека потому что он не знает или не достаточно знает одну технологию из тысяч ?

пора бы уже понимать, что озвученная причина отказа только в порядке исключения соответсвует реальной причине

ну тогда как по мне — надо бы сочинять отказ опираясь на общие формулировки, а не по принципу — у него в резюме не написано то, что у меня в методичке... Хотя чего это я — вспоминая о принципах работы HR описанных на ебаном, тут вообще не надо было что либо комментировать или акцентировать внимание.

Да не кидайтесь же бисером, без толку.

:) вы не представляете какой дефицит общения у меня — девятый год надомной работы дают о себе знать, :) так хоть с тролем какашками покидаюсь :)

пусть успокаивает себя, что общается с тролем))) Сам же подтвердил что дома мозг опух)

методология она одна

при чем методология DevOps не предусматривает никаких выдуманных позиций вроде DevOps engineer
это к тому

«кто как интерпретирует»

девопс инженер это человек, который работает по методологиям девопс, а не единица, описанная методологией.

DevOps QA
DevOps Developer
жгите дальше :-)

бред не несите, пожалуйста.

бред не несите

вот именно

вот именно, не несите. А лучше почитайте разницу между «инженер» и QA, и Developer

«инженер»

все таки осознаете :-)

Чувствуется, что писалось по наболевшему. Хотя я не понял, какая связь между Бобом и Сергеем Петровичем, и при чём тут вообще проблема некомпетентности менеджера. Кстати, кого именно он прогнал за «Ты меня не любишь»? Неужели Элис? ;)

Это про жизнь админа который вырос из коротких штанишек в далёкие времена, когда слово puppet означало игрушку, а средство доставки конфига на конечную платформу, будь-то полновесная ОС или какой-нибудь апач, не имело значения, ценилось только качество этого конфига и знание этой конкретной технологии, когда люди знали что такое оптимизация. И этот админ пошёл в большой проект потому что тоже хочет условный БМВ, а там люди с макбуками думают что они имеют отношение к ИТ. И вот эти люди теперь ведут ИТ в светлое будущее.
Сам это вижу каждый день.

Devops — это не «кто», это — «как». Если вна галере не понимают этого — лесом такую галеру.

Devops

Это Development Operations
Это либо Девелопер который знает оперейшн, либо оперейшен который знает девелопмент.
т.е. это либо девелопер который кроме того что знает как написать код, знает еще как развернуть ОС/виртуализировать/автоматизировать/задеплоить/настроить/мониторить/бекапить/затюнить/обновить/засекьюрить/предоставить доступ...
Либо админ, который знает что, где и как там в коде работает, к чему подключается, откуда сорсит, где найти ексепшены, плюс знает почему это не работает на данной платфоме и что надо сделать чтобы заработало и не падало.
Бритва Оккама

если смотреть глубже, то и те другие по отдельности — динозавры, и должны вымереть со временем, потому что инфраструктура уже сейчас рассматривается как код, а код рассматривается как набор модулей и фреймворков.

Это DevOps engineer, а DevOps это методология

Но все таки значительно чаще (и тут я соглашусь) devops определяется как процесс ... типа

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

Хотя и создают такие должности, подразумевая больше админов ... но оригинальная идея не в том.

Я же написал про Бритву Оккама
методологии-шметодологии, а потом базы падают а девопсы 4 дня ищут бекапы.
поднимается P1, собирается борд, обсуждаются KPI и принимаються решения про новые методологии.
— а вот если бы мы использовали боберпропер, мы бы вышли сухими из воды.

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

А опсы + девелоперы должны общаться и знать достаточно тонкостей работы друг друга на проекте — тогда бэкапы не потеряются. Хотя и задачи у них разные и знания нужны разные и SWE != SRE

если смотреть глубже, то и те другие по отдельности — динозавры, и должны вымереть со временем, потому что инфраструктура уже сейчас рассматривается как код, а код рассматривается как набор модулей и фреймворков.

Ну с одной стороны это частично произошло достаточно давно. Заметная часть старой админской работы за счёт улучшения дистрибутивов ушла или стала автоматизироваться, а необходимость держать заметные группы железного скота привела к необходимости использования средств автоматизации.
Отсюда все эти puppet/docker/etc.

Но привязываться к самим этим средствам нелепо — состав меняется каждый год. Остаётся общая способность и накопленное разнообразие опыта, которые такие Элис как раз неспособны оценить.

Вот с другой стороны — смещение разрабов в девопы — скорее всего просто не имеет смысла. Разве что на самих себе испытывать средства доставки :)

Заметная часть старой админской работы за счёт улучшения дистрибутивов ушла или стала автоматизироваться

Я не совсем эту часть имел в виду. Старая админская работа тут вообще не при чём, и на самом деле там не так уж много поменялось. Всякие приблуды для автоматизации инфраструктур были и 15 лет назад.
Я скорее имел в виду такие штуки как AWS CloudFormation, Azure ARM Templates где не нужен админ чтобы поднять вебсайт и не нужен девелопер чтобы на этом вебсайте разместить кнопочку. Ну не всё ещё так гладко, но прогресс очевиден, осталось допилить всего пару ништяков и туда перейдут все. Ентерпрайз уже почти весь там, потом компании поменьше. Нет своей инфраструктуры — не нужен персонал чтобы её обслуживать.

Заметная часть старой админской работы за счёт улучшения дистрибутивов ушла или стала автоматизироваться, а необходимость держать заметные группы железного скота привела к необходимости использования средств автоматизации.

Такой необходимости уже нет, по крайней мере у компаний чуть посолиднее чем «Рога и Копыта», и случилось это совсем не благодаря улучшениям дистрибутивов. Остается разве что банкинг, медицина и может быть что-то ещё что зарегулировано местными законами, как например в UK (Data Protection Act), прямо запрещающий британским компаниям хранить данные о пользователях за пределами UK, из-за чего Амазону пришлось открыть второй ДЦ в UK (в Лондоне) чтобы местные компании могли использовать Geo-Redundancy и High-Availability.
Первыми вымрут админы, т.к. их работа лучше поддается автоматизации, затем подтянутся девелоперы. Сегодня мы наблюдаем лебединую песню ИТ (и тру-админов и девелоперов), в том виде в котором оно появилось на свет. Нынешний Генри Форд уже приспособил конвеер, ИТ перестало быть творчеством и превратилось в ремесло. А я помню когда в Readme.txt было написано имя автора(-ов), как когда-то на двигателе присутствовал автограф механика. А с другой стороны, мы просто перейдём в Элит-класс где по-прежнему платят за то что твой автограф там есть.

Я скорее имел в виду такие штуки как AWS CloudFormation, Azure ARM Templates где не нужен админ чтобы поднять вебсайт и не нужен девелопер чтобы на этом вебсайте разместить кнопочку. Ну не всё ещё так гладко, но прогресс очевиден,

Сколько таких средств было и ушло, Вы себе не представляете. И все страдали тем, что «не нужен админ» только для самых тупых случаев, и «не нужен девелопер» только для самой простой кнопки. Как только выходим за пределы отработанного сценария — начинается необходимость чего-то повыше. А если учитывать неизбежное желание любого заказчика превратить своё простое средство в суперкомбайн... «прогресс» совсем не очевиден.
Вот честно — я бы тут больше поверил в перспективность средств вроде Wordpress. В которых разрабы всех видов таки нужны, но после этого покрывается очень широкий спектр возможностей. И даже «просто админам» (ну, или на грани с девопами) там есть чем заняться.

Ентерпрайз уже почти весь там

Enterprise на ARM Templates — или надо ржать безудержно, или сверить понимание слова «enterprise». Для меня это всё-таки то, у чего есть несколько разных направлений работы IT-систем и требуется достаточно глубокая их разработка и кастомизация (это не определение, а констатация).

Старая админская работа тут вообще не при чём, и на самом деле там не так уж много поменялось. Всякие приблуды для автоматизации инфраструктур были и 15 лет назад.

15 лет назад ещё каждая четвёртая конторка сидела на коаксиале и Win98. Если бы Вы сказали про 10 лет назад, я бы ещё согласился. А ушло из админской работы достаточно многое — начиная с того, что всякие Windows наконец перестали массово падать и обзавелись средствами восстановления ;) и что из сетей ушли раритеты всех видов.
И «приблуды для автоматизации инфраструктур» практически отсутствовали, если сравнивать с современным. Потому что для состояния этого года главная «приблуда» зовётся не puppet, а VM hypervisor (под любым из [не]коммерческих имён и совершенно не обязательно на облаке). Главная — не значит решающая основные проблемы; но это такая, без которой всё остальное становится невозможным. Как фиксатор обратного хода в «Музыкальной шкатулке».

Такой необходимости уже нет, по крайней мере у компаний чуть посолиднее чем «Рога и Копыта»

Под «держать» я имел в виду в том числе и «арендовать в AWS» и тому подобные варианты. Необходимости — да, нет, они могут и собственный ДЦ поставить :)

Первыми вымрут админы, т.к. их работа лучше поддается автоматизации, затем подтянутся девелоперы.

Не вымрут ни те, ни другие. Вы рассказываете нелепые рекламные сказки.
Может, простой пользователь без админа и сможет открыть себе систему на AWS с типовым вебсайтом. Но на первой же существенной проблеме ему нужно будет или сносить её в ноль и ставить другую, или ставить несколько там, где достаточно одной, или таки звать спеца, который способен понять, что значит хотя бы банальное «pool overflow» и как его лечить.
Точно так же и с девелоперами — как только необходимый алгоритм выйдет за пределы одношагового «нажми на кнопку — получишь результат» ©, мозг типичного пользователя откажет. Неудивительно — тут тоже надо тренироваться месяцами (а не «войтивайти»).

Нынешний Генри Форд уже приспособил конвеер, ИТ перестало быть творчеством и превратилось в ремесло.

Это «превращение в ремесло» происходило уже минимум дважды. И что-то оно так и не превратилось.

Сколько таких средств было и ушло, Вы себе не представляете

Эти — особенные, то с какой агрессией они сейчас работают и показывают результат, заставляет их принимать всеръез. Они уже никуда не уйдут. Скептики ещё лет 5 назад пророчили смерть всем клаудам.

Enterprise на ARM Templates — или надо ржать безудержно, или сверить понимание слова «enterprise»

Внезапно, enterprise это часто C# —> Visual Studio (incl. online) —> готовый ARM template на выходе. Расскажите C# девелоперу про деплой микросервисов на Service Fabric в AWS или On-Premise, он будет безудержно ржать вместе с вами. А в Ажуре развертывание Service Fabric кластера это «easy button». Так что мимо.

15 лет назад ещё каждая четвёртая конторка сидела на коаксиале и Win98. Если бы Вы сказали про 10 лет назад, я бы ещё согласился. А ушло из админской работы достаточно многое — начиная с того, что всякие Windows наконец перестали массово падать и обзавелись средствами восстановления ;) и что из сетей ушли раритеты всех видов.

По поводу 15 лет — это мой личный опыт, у вас он может отличаться.
Про падающий виндовс — ну сколько же можно, не заставляйте меня шутить про кривые руки.
prntscr.com/fn6lv5
Местами энтропия только увеличилась.

И «приблуды для автоматизации инфраструктур» практически отсутствовали, если сравнивать с современным.

Первый релиз SCCM (SMS) состоялся в 1994 году.
CFEngine — в 93-м

Не вымрут ни те, ни другие. Вы рассказываете нелепые рекламные сказки.

Ну не вымрут, их будут арендовать на время запуска, они переквалифицируются в консультантов, но фуллтайм как явление исчезнет со временем. Там где раньше работало 20 инженеров, сегодня 5-6.

Они уже никуда не уйдут. Скептики ещё лет 5 назад пророчили смерть всем клаудам.

Вы таки не путайте. Облако как общий метод — да, никуда не уйдёт. Может быть вариация, что вместо общего облака будет частное, миграции между облачными провайдерами и их стилями работы, и т.п. Но сам по себе подход «много мелких систем, которые невыгодно выделять в отдельные железяки => виртуалки; регулирование объёма ресурсов (RAM, etc.) по необходимости => виртуалки» никуда не денется и будет даже развиваться. А вот конкретный puppet вполне может через полгода скончаться в пользу другой тулзы — и судя, например, по этому отзыву — уже местами уходит.

Внезапно, enterprise это часто C# —> Visual Studio (incl. online) —> готовый ARM template на выходе.

Судя по статистике, «часто» это таки или около 50%, или менее. Хотя бы из-за конкуренции с Java. Это даже если не учитывать всех остальных вариантов, что и как может работать.
Так что сверка таки нужна.

Про падающий виндовс — ну сколько же можно, не заставляйте меня шутить про кривые руки.

2003 это уже изделие эпохи более-менее стабильности. Я говорил про более ранние. Но такой аптайм намекает, что его не апдейтят аж никак. Это уже противоположная проблема — но признак недоработки админов.

Ну не вымрут, их будут арендовать на время запуска, они переквалифицируются в консультантов, но фуллтайм как явление исчезнет со временем. Там где раньше работало 20 инженеров, сегодня 5-6.

А эти 5-6, что, не на фуллтайме будут? Ни одного из них? Ой не верится. Ну и обоснований таких тенденций я пока не вижу.

Но такой аптайм намекает, что его не апдейтят аж никак

Знаю, мопед не мой (кастомера), просто разместил обьяву (заскринил)

DevOps — это только методология. DevOps инжинер — это инжинер, который входит в команду, которая работает по методологии DevOps.
Release engineer
Software engineer
Site reliability engineer
NOC engineer
etc engineer..
И все они будут DevOps инжинерами. То, что у нас в стране принято ДевОпс инжинерами называть релиз инжинеров, не меняет сути методологии...

Позвольте я немного прокомментирую и дополню список

Release engineer — админ котороый умеет настроить puppet/ci/etc.
Software engineer — без комментариев, это программист
Site reliability engineer — админ который может настроить нормальный кластер ВМ или контейнеры на разных ДЦ или лоад балансер
NOC engineer — админ который может настроить мониторинг/алерты
Backup engineer — просто админ делает и тестит бекапы
Test engineer — админ который перед тем как задеплоить на продакшн протестит на соседней виртуалке
Update engineer — обновляет ОС/платформу, следит за актуальностью софта
Information Security engineer — админ который не раздает права всем подряд, дизайнит политики, проводит аудит секьюрити групп, не записывает пароли на бумажке или в плейнтексте, следит за появлением уязвимостей и патчит дыры. Это наверное самая сложная штука, поэтому редко попадает под понятие девопс.
Infrastructure Support engineer — админ которому приходит алерт с мониторинга и он чинит то что упало. Часто, эти же люди занимаються деплойментом и настройкой underlying infrastructure, про которую девелоперы часто ни сном ни духом.
Network engineer — админ который умеет настроить сеть/впн/рулы. Разрулить доступ в инет и доступность из мира.

98% случаев это админ, если админ адекватен — то он всесилен и потянет этот список без проблем для проекта средней паршивости. 2 и больше адекватных админов — уровень God если их не отвлекать митингами.
Если админ только джун — то таких джунов должно быть действительно целая комманда, может именно поэтому топик новит название «DevOps — корпоративная „лычка“ для джунов», хотя соглашусь, что автор может плавать (как и я) в понимании чем DevOps отличается от DevOps engineer, сути это не меняет. Мне просто никто так и не смог внятно обьяснить чем DevOps engineer отличается от админа.

Почему, и кто решил меня переименовать в эфимерный «ДевОпс инжинер», для меня остается загадкой, меня наверное хотят запутать. Скорее всего просто слово красивее чем «админ». Возможно само слово админ у рекрутеров, девелоперов и ПМ-ов уже просто вызывает негативные ассоциации, типа ленивое хамло которое норовит поржать над ламерами (хотя это не так).

Пожалуйста, приведите какой-нибудь пример ДевОпс инжинера, который не ассоциировался бы с админской работой, кроме собственно Software engineer. Буду благодарен.

То, что у нас в стране принято ДевОпс инжинерами называть релиз инжинеров, не меняет сути методологии...

Признаюсь честно, этот вопрос меня мучает, я гуглил ещё лет 5 назад что это такое, не понял отличия от админа. Погуглил свеженькое, не сособо нашел, Википедию стыдно читать ибо вода и увеличение надоев с одного гектара, никакой конкретики.

AWS умеют делать быстро надежно и грамотно и они для меня авторитет в плане таких глубоко технологичных аспектов, давайте посмотрим что они называют ДевОпс инженером
aws.amazon.com/...​tions/devops-engineering


Intended Audience
This course is intended for:

* System Administrators
* Software Developers

Prerequisites
We recommend that attendees of this course have the following prerequisites

* Attended Developing on AWS or System Operations on AWS course
* Working knowledge of one or more high-level programming languages (C#, Java, PHP, Ruby,
Python, etc.)
* Intermediate knowledge of administering Linux or Windows systems at the command-line level
* Working experience with AWS using both the AWS Management Console and the AWS Command Line Interface (AWS CLI)

Вот это уже что-то конкретное. Если перевести на человеческий язык — то будет приблизительно то же самое что я сказал выше:

Это либо Девелопер который знает оперейшн, либо оперейшен который знает девелопмент.

Прошу прощения, но Вам бы для начала определится с ролями инженеров.
SRE — Fundamentally, it’s what happens when you ask a software engineer to design an operations function.
Release engineering — frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components.
NOC и Network у Вас разные понятия, ну ок.
Ну в общем, я хотел донести мысль, что те роли, которые на самом деле являются отнюдь не админскими и где главная цель — это написания кода, который просто напросто реализует не «бизнес фичи», а внутренние потребности компаний, многие люди, как и Вы в том числе, ошибочно считаете «админскими» ролями.
Есть разница в написании системы мониторинга и в её эксплуатации, есть разница в написании конфиг.менедж.системы и в написании «плейбуков/рецептов» под неё.
Вот в этом и разница между SRE/RE/..E. и «админами». Первые создают продукты которые нужны компании, вторые исключительно эксплуатируют.

SRE — Fundamentally, it’s what happens when you ask a software engineer to design an operations function.

Когда девелопера просят сделать то что является работой оперейшена (админа), получается приблизительно то же самое что и наоборот, админ пишет код на условном Java.
500 Gateway error — вот что будет скорее всего, если это конечно не девелопер гуру.
Те девелоперы которых я лично знаю и которые работают по «методологии ДевОпс» не могут SSL offloading осилить.

кстати, в этой же статье, со слов того же гения, Ben Treynor на которого вы молитесь

During our hiring process, we examine people who are close to passing the Google SWE bar, and who in addition also have a complementary set of skills that are useful to us. Network engineering and Unix system administration are two common areas that we look at; there are others. Someone with good software skills but perhaps little professional development experience, who also is an expert in network engineering or system administration — we hire those people for SRE. Typically, we hire about a 50-50 mix of people who have more of a software background and people who have more of a systems engineering background. It seems to be a really good mix.

Really? вы называете ЭТО ролью SRE? набрали 50% админов и 50% девелоперов и обьединили их в отдельный тим.
в Гугл — да, это отдельный тим, они могут себе такое позволить.
а в жизни, если вы откроете такую вакансию — все будут с вас смеятся.

Мы ищем админа или нетворк админа (SRE), в обязанности которого будет входить не только мониторинг живучести и доступности аппликейшена, но и моментальный фикс того что на%$&нокодили наши девелоперы и пропустили наши тестеры. Вот такой у нас проект, зато у нас есть теннисный стол.

NOC и Network у Вас разные понятия, ну ок.

Да, очень часто это разные понятия. Если коротко, NOC — это L1, Network engineer — это L2 или L3.

Извините, после таких противоречий, всё сказанное Вами ниже, не имеет смысла комментировать.

Если коротко, NOC — это L1, Network engineer — это L2 или L3.

NOC — это L2/L3, местами на L4. L1/L2 это канальщики, отдельный профиль работы, хотя их часто и называют network engineer. Так что тут «немного» наоборот.

В остальном скорее согласен — что гугл свои devops сделал как-то сращением ужа с ежом. Но это вполне может быть началом уже нормально кристаллизованного подхода.

NOC — это L2/L3, местами на L4. L1/L2 это канальщики, отдельный профиль работы, хотя их часто и называют network engineer. Так что тут «немного» наоборот.

Вы хоть не будете спорить с тем что:
1. NOC — это 24/7
2. Основная часть работы NOC — это пялиться в 40-80 дюймовые мониторы развешенные под потолком

Вы себе представляете сколько будет стоить «L2/L3, местами на L4» в ночную смену, в том же Гугле? А стартап потянет такую з/п минимум трем людям, потому что один человек не сможет смотреть в монитор 24 часа и смена строго определена законодательно. И где стартап найдёт трех L2/L3 инженеров?
Ещё раз, NOC — это дешевый L1 джун, который может пингануть, трейс запустить, зарегистрировать инцидент, и эскалейтить на On-Call engineer если алерт не починился сам через 15 минут. Если много красного на мониторах — они ещё конференц-колл сетапят и подключают туда Head of IT.

В моей практике это были всякие филлипинцы/тайванцы, и когда они мне в 3 часа ночи звонили я на всю квартиру угорал с их акцента. А разговор как правило заканчиваля фразой «Drop me an e-mail please».

Вы хоть не будете спорить с тем что:
1. NOC — это 24/7

Ну в общем да. Но не только они, вообще-то :)

2. Основная часть работы NOC — это пялиться в 40-80 дюймовые мониторы развешенные под потолком

Эээ... really? Я всё-таки полагаю, что люди обычно способны лучше оптимизировать свою работу, в плане выделения проблемных ситуаций.

Наши опы не занимаются постоянным пялением «в 40-80 дюймовые мониторы развешенные под потолком», мониторинг вылавливает проблемные ситуации. Вот после их обнаружения можно и попялится.
Если где-то постоянно пялятся — значит, там сильные недоработки.

Ещё раз, NOC — это дешевый L1 джун

Блин... я имел в виду под Ln — уровень схемы OSI, за который отвечает соответствующая служба. А Вы — номер условной линии техподдержки, да?

В любом случае, я не знаю, в каком таком неприличном месте исказили так, что «NOC — это дешёвый L1». Но спорить не буду, если в ваших краях приняты такие термины — вам с этим жить.

конечно я имел в виду уровень поддержки

а обычная комната NOC выглядит вот так
и всё что они там делают — пьют кофе и пялятся в мониторы, а когда покарснеет — звонят на тот телефон который у них записан на прикрепленном к монитору стикере.
Они не за своей работой следят, они за всем следят. Вообще за всем.
Для этого инфра им выводит на отдельный монитор како-нибудь Zabbix/Nagios
Нетворк инженеры на другом монике с MRTG/Solarwinds
Девы — дают консольку New Relic
и т.д.

В зависимости от того кто накосячил — тому и звонят, чаще — всем сразу ибо понятия не имеют что вообще происходит, они же джуны.

Release engineer — админ котороый умеет настроить puppet/ci/etc.

Я знаю этот термин в ином смысле — это тот разраб, кто создаёт конечную форму выходного продукта (релиза), занимается сборочными скриптами и т.п.
Хотя пересечение тут есть, если считать, что «форма» выходного продукта определяется тем, что и куда разложили puppet, Jenkins и иже с ними.

NOC engineer — админ который может настроить мониторинг/алерты

А также «просто» настроить сеть, чтобы она работала как надо (ширины каналов, раутеры, средства динамической маршрутизации, балансеры на уровне IP, и т.п.) — это тоже относится к NOC и предельно плотно связано с мониторингом.

Мне просто никто так и не смог внятно обьяснить чем DevOps engineer отличается от админа.

Красивое переименование для отражения того факта, что работа такого инженера это больше не лазанье за каждым чихом напрямую, а управление средствами, которые это делают за него.
Для некоторых... мнэээ... менеджеров это важно.

Вот это уже что-то конкретное. Если перевести на человеческий язык — то будет приблизительно то же самое что я сказал выше:

Это либо Девелопер который знает оперейшн, либо оперейшен который знает девелопмент.

Такое определение как-то никуда практически не применимо. Просто «знать» недостаточно.

Я бы свёл (для начала) devops к случаю автоматизированного непрерывного обновления рабочей инфраструктуры. Только тогда оно начинает существенно отличаться от «простого» админства, и (как выше говорил) неизбежность автоматизации.

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

Да, Элис оказалась именно такая.

да да, Элис именно виновата во всех бедах! Правильная Л — логика))

Подписаться на комментарии