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

Удалось потрогать портал обучения от LinkedIn. Ценник у него такой же, как у Pluralsight, и меньше, чем у LinuxAcademy.
Из плюсов - огромный выбор курсов, в том числе и не связанных с ИТ. Дизайн, маркетинг, вот это вот все.

Из минусов - в основе обучения лежат видеолекции с небольшими лабами, которые качаются и делаются локально. Закрепленность знаний проверяется небольшими тестами, не дающими понимания, что полученная информация закреплена на практике. Но этим же страдает и Pluralsight.

Правда, открыл курс основ по веб-разработке и дизайну (совсем нулевый), и в первой же секции идет дубовое пояснение основ HTML, CSS и, простите, JavaScript.
Особенно раздражает, когда лектор с сияющими глазами говорит: “Да, это выглядит довольно сложно, но, поверьте, это очень легко!”
Вот… честно, не люблю таких преподавателей. Их мотивация понятна - им нужно стимулировать все больше новичков входить в сферу ИТ, но так не делается.

В последнем голосовании, люди 10 раз нажали на инопланетянина. Я позволю себе предположить, чтобы вы либо имеете косвенное отношение к ИТ, либо вам интереснее, когда я пишу про свои приключения с газовыми компаниями.

Но на всякий случай, если вы однажды захотите начать (или продолжить) карьеру в ИТ: неважно, какое направление вы выберете, будь то дизайн, разработка или системная инженерия - ИТ это НЕ легко.
Как и любая другая интеллектуальная деятельность, ИТ требует навыков и знаний, которые необходимо приобрести, прежде чем начать бороздить просторы рекрутинговых сайтов. Это не значит, что нужно бросать все и поступать в МГТИ имени Баумана, но придется инвестировать в себя деньги и время.

Любой, кто скажет вам “ИТ это легко” - лжец и подлец. “Гоните его, насмехайтесь над ним.”

Продолжаю играть с голосовалками. Опрос для ИТ спецов и всех, кто с ними связан.
Какого рода вы ИТ спец (разработка или администрирование)
- 😃 - если вы по Microsoft (Windows Server, Powershell, OctopusDeploy, etc).
- 😍 - если по Linux (RedHat, Ubuntu, bash, etc).
- 😳 - если оба.

Яндекс индексирует документы в Google Drive. Если у вас там что-то важное - убедитесь, что это хорошо спрятано за настройками приватности. Яндекс вроде это дело исправил, но береженого Бог бережет.

Ну и помним, что хранить пароли и явки где-то в облаке у Гугла - absolutely haram.

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

Компании стали применять DevOps по-разному. Те, кто уже использовал популярные framework’и Agile, например Scrum, поставили инженеров в “продуктовые” команды. То есть у вас есть команда - разработчики, тестировщики, инженеры. Поскольку Scrum подразумевает кросс-функциональные команды, на выходе мы имеем разрабов, которые немножко сисадмины, и сисадминов, которые немножко разрабы.

В целом неплохо, и такая модель хорошо работает, правда у нее есть и свои недостатки. Например, когда у вас продуктовая команда как вещь-в-себе, она пилит проект так, как ей удобно. Платформа, ОС, язык программирования, DevOps tools - все выбирается самой командой и строго под ее нужды. Если у вас много продуктовых команд, то вы получаете потрясающий бардак и зоопарк, где команда А уже сидит в Кубере с этими вашим докером, а команда Б все еще делает golden AMI в AWS во время релиза новой версии приложения. Сравнить KPI (а топы очень любят KPI) таких команд тяжело, поэтому проверить эффективность той или иной команды становится тем еще приключением.

Другие конторы, чаще всего крупный сектор с headcount в 5000+ человек и миллиардным оборотом, стали делать отделы - отдел FrontEnd разработки (их может быть много), Baсkend разработки (тоже может быть много), отдел инфраструктуры и, простите, отдел DevOps.
Вроде silo - все сидят в своих уголках и что-то там делают. Взаимодействие уже не такое шустрое, люди могут сидеть в разных офисах, если не городах или странах - сложно просто подойти и поговорить ртом. Но и такой подход имеет право на жизнь, и вот почему.

Когда вы инженер в DevOps отделе, вы “поддерживаете” разработчиков. В ваших интересах, чтобы разрабы спокойно и без лишних проблем выкатывали новый код в production, а вы, если что, быстро его откатите обратно. Если вы инженер инфраструктурного отдела (допустим у вас в 2018-ом до сих пор свой ЦОД), то вам нужно, чтобы серверы и сеть работали без перебоев.
Такие потребности позволяют создать сервисно-ориентированные команды. Infra-команда не предоставляет железо - она предоставляет сервис, где каждый может “заказать” себе виртуалку. DevOps команда не предоставляет тулзы - она предоставляет сервис для управления приложениями.

Поскольку такие команды обладают бОльшей экспертизой в инструментарии, нежели сами разработчики, то они дают им один инструмент под определенную задачу, например, Puppet/Ansible/Chef для управления серверами, Terraform/Cloudformation для создания новых ресурсов, Jenkins/Teamcity для CI/CD, Github/Gitlab/GitUNameIt для хранения исходников, ну и всякие Linter’ы и прочие финтифлюшки. У разрабов особо нет выбора, и они пишут приложения, придерживаясь каких-то общих, зачастую навязанных административным ресурсом, стандартов.

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

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

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

Неоднозначную реакцию общественности вызвала парадигма разработки serverless - якобы приложения без серверов. Если не язвить, что говорят так люди, не знающие, как устроены компьютерные программы, то можно увидеть идею за следующим.
Serverless дает возможность разрабатывать и запускать приложения без предварительной настройки платформы (будь то ОС, веб сервер или сервер приложений). Написал код - прогнал тесты - запаковал - отправил на AWS Lambda. Хочешь на Python, хочешь на Java/JavaScript, хочешь на C#. Та же Lambda вкупе с другими managed сервисами AWS позволяет нам писать полноценные приложения с минимумом компьютеров в обслуживании.

Вот, например, мой любимый интернет магазин плюшевых хомячков. Написали статичный сайт, положили его в S3. Нажали на нем кнопочку “Добавить в корзину”, делается API вызов на Lambda через API Gateway. Lambda отработала, и вы видите цифру “1” напротив вашей корзины. Нажали “Заказать” - отработало. “Оплатить” - отработало. Несколько маленьких программ, выполняющих свою работу, небольшой сайт c JavaScript, S3, чтобы держать там ваш сайтик, и какое-нибудь хранилище - для пользовательских данных, товаров и прочего. Ни одного сервера под непосредственным управлением. Красота.

Далеко не все приложения сегодня могут действовать по-похожему принципу. Автоматизированные банковские системы, ERP/CRM системы и прочие до такого не скоро дойдут. Большие компании тоже - уж слишком много денег и времени вбухано на текущие разработки.

Тем не менее, начало положено. Кто-то сразу смекнул, что из этого можно сделать, кто-то не понял, но на всякий случай “заорал” и написал про NoOps, кто-то поморщился и пошел дальше админить свой сервер Ubuntu. Ну или кластер Kubernetes (кому как нравится).

С другой стороны управление инфраструктурой все больше отодвигается, давая дорогу к управлению приложениями. Немало сил приложил к этому сам Kubernetes, который может расширяться сам, без сторонней помощи инженерных групп. К нему уже придумали Helm - пакетный менеджер для приложений Kubernetes (аналог Universe для DC/OS). Если так дальше пойдет, то кроме Кубера ничего и знать не нужно будет.

Не отстает от прогресса и сам Amazon. Сервис Fargate, который позволяет развертывать Docker приложения на ECS/EKS кластеры без надобности управлять теми самими кластерами, лишает нас необходимости думать о “железной” части. К приложению легко цепляется ELB/ALB/NLB, что дает нам какой-никакой Service Discovery. Просто прелесть.

Что нас ждет дальше? Docker будет потихоньку превращаться из контейнера в своеобразную очень легкую виртуальную машину со своим state, что навсегда уничтожит границы между контейнерной и гипервизорной виртуализацией. Serverless будет находить своих поклонников среди маленьких стартапов, где не хотят тратиться на инженеров-инфраструктурщиков. Архитекторы решений потихоньку переобуются в архитекторов систем, и будут проектировать приложения вместо инфраструктур. Сисадмины будут мониторить и логгировать приложения, а не серверы. Железячники и сетевики, конечно, никуда не денутся (кто-то же сидит в ЦОДах Амазона, Гугла и Микрософта), но количество предложений на рынке труда уменьшится.

А мы с вами будем сидеть на Безусловном Базовом Доходе, потому что наша работа будет не нужна. Имея необходимые средства к существованию, мы посвятим себя науке, искусству и творчеству, пока искусственный интеллект и роботы за нас пишут код, собирают и обслуживают оборудование. Бизнес будет заказывать приложения “голосом” через voice recognition, а бездушная железяка будет их создавать.

Тем и спасемся.

Посвящается Валере и @DevOpsOnCall. Контора решила не отставать от прогрессивных компаний и внедряет дежурства.

Говоря о будущем, нельзя не упомянуть всеми любимую (и нелюбимую) криптуху.

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

Поскольку проект запустился в открытом бета режиме с мая 2018-ого, мы получили рост пользователей выше прогнозируемого и были вынуждены переехать на AWS раньше срока (старый ДЦ не давал возможностей для расширения). Пока мы не начали «агрессивный» «маркетинг» пользователи приходили через сарафанное радио, а значит были достаточно опытными (большая часть была в крипте еще до 2013-ого). Было у нас порядка 200 человек, 100 с лишним из которых были в группе «пожизненно бесплатно» - эти товарищи первыми рискнули вложить свои средства в торговлю на GSMG, тем самым показав нам свое доверие и завоевав наше. Этим ребята стали «адвокатами»: они продвигают робота среди своих тусовочек и помогают новичкам в общих чатах.

Но надо как-то зарабатывать деньги, и мои партнеры по бизнесу начали сотрудничать со всякими голландскими криптосообществами, чтобы привлечь побольше людей. Что же из этого получилось? Как и раньше, в этих ваших интернетах все еще огромное количество «dumb money» (глупых денег). Люди, вложившие в крипту на волне общего «хайпа», ожидают бешеного роста и прибылей в 100-150% в первые несколько дней. Среди таких самый стандартный вопрос - почему робот работает полчаса и до сих пор не заработал на Ламбо.
Хуже того, люди абсолютно не умеют (или не хотят) читать и отправляют деньги на наш кошелек, не зная о его предназначении (средства на нем «оплачивают» работу платформы, а не участвуют в торгах). Люди отправляют от 5 до 10 эфиров (от 2000 до 4000 $), а потом слезно просят их обратно. «Я отправил, а потом прочитал руководство, верните, пожалуйста!»
Все это раздражает, ведь от людей, которые реально часть своих сбережений держат в крипте (нет лучше способа спрятать их от налоговой), ожидаешь какой-никакой финансовой и технической грамотности.

Не помогает “бизнесу” и испортившие репутацию торговых платформ финансовые пирамиды, например BitConnect, и платформы, не сумевшие вовремя подстроиться под изменившийся рынок и обвинившие в этом биржи (TraderDaddy, по сути наш основной конкурент). Из-за таких кадров на 10 человек приходится 2-3 гения, утверждающих, что мы лжецы и подлецы и хотим забрать все ваши деньги (Хотя наша платфома технически на это неспособна).

Ловел (тот самый друг хорват, посадивший меня на этот веселый криптокорабль), относится к ним с состраданием. Какой бы ни был человек, умный или глупый, клевый или занудный - он все еще наш клиент, и если он не заработает, то и мы не заработаем (наша бизнес-модель заключается в “сжигании” суммы, равной 25% от прибыли с торговой пары из “топлива” пользователя, пользователь “платит” за робота, отправляя средства на наш кошелек, тем самым пополняя “топливо”).

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

Очередной опросик. С платформами и пожеланиями людей опредилились, теперь интересно, как вы связаны с криптухой.
Без холиваров типа “биток против альтов” и прочего.
Вопрос простой - есть ли у вас крипта?
🤖 - есть.
😳 - нет.

Раз тут аж больше 20 человек, то милости прошу к нашему шалашу: https://gsmg.io

За помощью сюда: https://help.gsmg.io
Телеграм тусовочка тут: https://t.me/GSMG_Bot (говорим по-английски).

У Скрама (один из фреймворков Agile) есть одна такая процедура, называется “Daily Scrum” (или Daily StandUp).
Заключается в простой встрече членов команды, где каждый рассказывает о достижениях вчерашнего дня и делах на “сегодня”. Простенькая встреча, которая должна всех друг с другом синхронизировать, ну и можно поднять животрепещущие вопросы.

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

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

Скрам требует определенной дисциплины и самоконтроля, он прекрасно подходит для маленький команд со свежим продуктом, будущее которого не ясно. В свою очередь, он совершенно не подходит для больших монолитных проектов и инженерных команд, особенно работающих реакционно, по входящим “тикетам”.

В интернете очень много споров на тему правильно и неправильно приготовленного Скрама, о важности роли Скрам-мастера и кому это роль нужно давать, но я не встречал обсуждений утренних стендапов. (Хотя тех, кто их не любит, я встречаю часто).

Больше всего мне понравился подход, который реализовали в одной смежной команде: у них стендапов нет, но каждое утро, во время когда должен быть стендап, все члены команды пишут небольшое письмо со своими “делами” своему тимлиду. Тимлид эти письма мельком читает и в случае конфликтных или потенциально конфликтных ситуаций назначает предметные встречи. Времени затрачивается минимум, переговорку искать не нужно, кто работает удаленно, не должен сломя голову бежать за микрофоном. Утопия.

Как только мой канал стал становиться все популярнее (я считаю успехом уже то, что меня читают больше 100 человек), я стал следить за количеством подписчиков, шо за этими вашими бетховенами.
Цифра растет - эйфория, радость, тщеславие.
Цифра падает - самоанализ, паника, «я слишком часто пишу», «я слишком редко пишу», «я пишу херню».

Если продолжить корреляцию с ценой биткоина, то понятно - канал вырос слишком быстро (особенно если учесть, что в продвижение не вложено ни копейки), и теперь количество «корректируется».

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

И пусть я очень рад, что вы со мной, я не буду «фильтровать» контент (в этом и преимущество авторского канала).

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

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

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

Марвел довольно крепко засел в киноиндустрии, денег там крутится огромное количество (не удивлюсь, если даже больше чем в индустрии комиксов), но что для меня стало “открытием”, так это их приверженность к… достоверности, если можно применить это слово к фантастическим комиксам для детей и детей-переростков.

У Марвела есть такой супергерой Тор, комиксовый вариант того самого Тора - бога грома из пантеона северных богов. Скандинавская мифология для меня тема новая и приглянулась после просмотра множества сезонов “Викингов”.
Я всегда считал, что Тор от Марвела был таким (нервным, драчливым, выпендрежным и честолюбивым), потому что так решили его нарисовать американцы. Но как только я начал чтение “Северных Богов” Нила Геймана, я открыл для себя немало прекрасного. Удивить после греческой мифологии сложно (один только Зевс, спящий со всем, что двигается, и его стервозная злющая жена Гера чего стоят), но северные мифы СМОГЛИ.

Вот просто один из многих мифов в книге. Итак, у Тора есть могучий молот Мьельнир, и в один прекрасный день его у него воруют. Тор по обыкновению решает, что это проделки его брата Локи. Когда выясняется, что это не так, Локи отправляется на поиски утраченного оружия массового поражения и находит преступника.
Украл его повелитель огров Трюм, который взамен возвращения молота домой желает жениться на богине Фрейе (вообще Фрейю все время ставят на кон, бедная женщина). Когда Локи возвращается в Асгард, товарищи устраивают совет, на котором решают отправить Трюму невесту. В качестве невесты отправляют самого Тора, предварительно одев его в женские свадебные наряды и навесив на него украшений. Дабы тот не раскрыл себя, с Тором на земли огров едет Локи, обернувшийся служанкой. Во время свадьбы, как только появляется молот, Тор срывает свое прикрытие, убивает всех огров и великанов вокруг и едет домой.

То есть еще раз - могучий Бог Грома и его брат-хитрость-во-плоти переодеваются в барышень, чтобы вернуть себе оружие, словно персонажи дешевой американской комедии с Джимом Керри в главной роли. Неудивительно, что Марвел представляет их такими же.

Не знаю, кто и под чем придумывал все эти мифы, но они прекрасны.

А еще у Тора есть колесница, в которую запряжены два козла: Ворчун и Дробила. Обожаю северную мифологию.

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

Поступила просьба разобрать карьерный вопрос для ИТшника - расти вверх (в менеджмент) или вширь (сеньоры, архитекторы и т.д.).

Сразу скажу, если хочется денег - однозначно вверх. Какую бы узкую специальность вы ни выбрали, менеджеры (тимлиды и все что выше) зарабатывают больше. В таком случае надо учитывать, в какой специализации вы планируете расти. Условный Senior Data Scientist будет зарабатывать больше FrontEnd TeamLead’а потому, что тренды, спрос и заинтересованность бизнеса (тимлидов пруд пруди, а толкового человека, шарящего в machine learning попробуй найди).
С другой стороны из тимлидов гораздо проще вылезти на ступень повыше (CTO - технический директор). Особенно если быть тимлидом команды, которая отвечает за core business приложения.

Другая причина, по которой люди могут пойти “наверх”, заключается в желании менять (и меняться). Человек может видеть организационные или процессные огрехи, но повлиять на них может только косвенно (чаще всего он может повлиять только на своего тимлида). Повлиять на смежные команды, не говоря уже про менеджмент повыше, не позволяет недостаток компетенций, всяких bigger picture и административного ресурса. Тебя наняли писать код и пилить приложения, так пиши код и пили приложения. Менеджеру это дается гораздо проще.

Третья причина проста и прозаична - надоедает. Надоедает писать, ломать, дебажить, тестировать, релизить и прочее. Если для вас работа не хобби (как в моем случае), то какие бы новые и веселые технологии, инструменты и фреймворки ни появились, вам все равно станет ужасно скучно. Роль менеджера немного разбавляет технологическую рутину рутиной организационной. Нужно планировать бюджет, выбивать себе вакансии, создавать для каждого подчиненного план развития, да и в целом - больше заниматься people management (где people - это люди в принципе, и не только в вашей команде).

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

Что касается линейки развития как специалист, то тут все просто: джун, мидл, синьор, в некоторых конторах principal (это прям еще круче, чем сеньор). Градация повыше показывает вашу как техническую подготовленность, так и определенный кругозор и набор soft skills, например - умение договариваться или вести презентации.

Другим аспектом горизонтального роста может выступать то же желание смены обстановки или желание менять.
Например, вы работаете разрабом в backend, и вас очень не устраивает работа инженеров из эксплуатации: тикеты отрабатывают долго, приложения лежат, мониторинг орет, вот это вот все. Что можно сделать? Придти к ним на помощь (заодно наладите связь с коллегами по ту сторону баррикад). Получается тройной выигрыш - и новые вещи делаете (освоить DevOps tooling, честно скажу, дело не хитрое), и коллегам поможете, и бизнес будет доволен. Такой “переход”, даже временный, дает возможность освоить новую для себя сферу и прицениться к потенциальной работе.
Из DevOps энтузиастов - людей, которые не просто пишут код и/или помогают развертывать и обслуживать приложения, но и разрушают барьеры между “красными” и “белыми” - потом вырастают опытные консультанты и архитекторы, которые “повидали некоторое дерьмо”. За таких в Европе очень много платят.

Стоя на перепутье карьерного роста, задайте себе несколько вопросов:
- Нравится ли вам ваша работа?
- Почему вам нравится/не нравится ваша работа?
- Нравится ли вам ваш доход?
- Нравится ли вам ваша команда?
- Что бы вы хотели в ней поменять?
- Что бы вы хотели изменить в своей жизни?

Еще один опрос для людей, работающих с DevOps.
Сколько вы в культуре? Именно в культуре, опыт работы с CFEngine со дня релиза не считается, общий опыт тоже.

🙃 - до года
😐 - от 1 до 3 лет
😊- от 3 до 6
😈 - от 6 и больше

В 2016-ом году на свет вышла книга за авторством нескольких сотрудников Google под названием “Site Reliability Engineering: How Google runs production systems”. Безусловно, у Google есть чему поучиться: компания предоставляет сервисы для миллиардов пользователей, и на своем опыте я не могу вспомнить, когда хоть какой-то из них слег так же жестко, как S3 в 2017-ом.

Однако, если открыть поисковик от Google и поискать там истории уволившихся сотрудников, ушедших либо на вольные хлеба, либо в стартапы, либо в другие конторы, мы начинаем понимать простую истину, касающихся 99.99% все ИТ-гигантов: Google не всегда все делает “правильно”, и я сейчас не о десятках экспериментальных проектов, которые были закрыты по каким-то внутренним причинам, а сотрудники, болевшие ими, либо ушли, либо были переведены в другие проекты.

Однако Google как, наверное, самый престижный ИТ гигант служит примером для всей индустрии и, пусть и неосознанно, но обладает огромным влиянием на бесчисленное множество крупных, средних и маленьких контор. Некоторое время после выхода книги про SRE, о создании SRE группы заявил LinkedIn - социальная сеть для соискателей и работодателей.

В отличие от DevOps, SRE, на мой взгляд, выступает полноценным фреймворком, поскольку содержит в себе конкретный набор инструкций по внедрению и применению. Основным различием является то, что SRE подразумевает наличие отдельной команды, состоящих из очень крутых специалистов, шарящих и в разработке, и в инженерии. Главным фокусом является не только обеспечение максимально высокого uptime, но и предварительный расчет оптимального значения оного (когда сравнивают расходы на uptime с потерями от падения) - нет смысла гарантировать максимум 10 минут “лежания”, если это стоит миллиард долларов, а “спасаете” вы миллион.

Эксперты SRE переходят в команду конкретного продукта по запросу самой команды. По “правилам” команда может взять либо одного SRE, либо одного feature разработчика. Проще говоря - если максимальный headcount вашей команды 8 человек (и у вас уже 8 человек), и вы хотите себе одного SRE, то придется одного разработчика из команды прогнать. Таким образом скорость доставки обновлений приносится в жертву стабильности продукта.
Есть еще одна “фишка” SRE - взятый в команду SRE эксперт может по собственному разумению уйти из продукта, если (цитата) “он видит, что действия команды по стабильности не эффективны и не приносят пользы”.

Когда мы говорим о применении такого подхода в Google, мы понимаем, что SREшник не покинет продукт просто так - он подставит не только команду продукта, но и себя (его экспертиза ставится под вопрос). Но если представить такое в, простите, русской конторе, где, еще раз простите, царит бардак - получим человека с завышенным ЧСВ, который не смог с полпинка поднять uptime до 99.999% и, плюнув на все, свалил.

На одном митапе про SRE в Амстердаме, презентер сказал, что SRE - это одно из применений DevOps. Других применений он назвать не смог (потому что их и нет), да и сама фраза в корне некорректна. DevOps - культура, увеличивающая скорость поставки за счет уничтожения процедуральных bottleneck и автоматизации всего что можно. SRE - подход, снижающий скорость поставки в угоду стабильности, добавляющий ненужный стресс продуктовым командам. При этом нигде не упоминается, что DevOps не увеличивает стабильность приложений (эффективное взаимодействие команд разработки и эксплуатации дает необходимый эффект).

В общем, к чему я это все. Google сделал немало хорошего для ИТ индустрии и подарил нам множество продуктов для конечного потребителя. Но это не значит, что:
1. Все что делает Google - правильно.
2. Все должны работать так, как работает Google.

Решайте проблемы бизнеса, создавая свои собственные или применяя проверенные временем решения. Не надо повторять все за старшим братиком, особенно когда тот подсел на наркотики.

Который раз натыкаюсь на такие прикольные словечки, как sourcing и influencer. Думал, что же это такое, и пошел гуглить.

Influencer это такая звезда в соц сетях, которая обладает влиянием на свою подписоту. Дескать и точку зрения свою протолкнет, и товар впарит (если заплатить, конечно).
Раньше модно было говорить, что звезда кино и сериалов является “лицом компании” (как например “Чудо-Женщина” Гал Гадот стала лицом Хуавей - причем настолько удачным, что похвалила телефон Хуавей в твиттере, запостив этот твит с айфона). “Влиятель” (я не знаю, как это еще можно перевести на великий и могучий) не является чьим-то лицом официально. Просто левый такой человек, который говорит, что А лучше Б. А мы на это ведемся, потому что он крутой (как Тема Лебедев или Юра Вдудь).

С “сорсингом” поинтереснее. Есть рекрутер. Рекрутер обрабатывает входящие резюме, ведет собеседования, участвует в принятии решений (я уже писал, что рекрутер в Нидерландах влияет на решение по кандидату не меньше, чем сам нанимающий менеджер), отсылает офферы и холодные письма с приглашением на собеседование (даже если кандидат по умолчанию не подходит - так было со мной, пока я не переехал в Нидерланды).
А вот “сорсер” (исходник? ковырятель исходников? Гугл не знает, как такое перевести) занимается тем, что сидит в соц сетях типа LinkedIn и находит потенциальные таланты, которым, если что, можно предложить приехать поболтать. Проще говоря, человек, занимающийся этим пошлым явлением sourcing, это такой PreSale - найдет, изучит, отправит в работу рекрутеру (Sales). Сам “сорсер” на работу или пообщаться не зовет.

У нас были миллионы гендеров, теперь у нас есть миллионы “новых” ролей.

Теперь по поводу картинки. Для начала уберем пункты, которые действительно правильные:
1. Не просите их починить принтер - хочется верить, что в 2018-ом году бизнес-пользователи видят разницу между разработчиком и helpdesk специалистом. Ежели нет - бегите.
2. Не ставьте себя выше них - спорный момент, но есть кадры, которые придерживаются правила “Заказчик == Бог”. Если у вас похожий кейс, то смотрите п. 1.

Вот в принципе и все, что в картинке “правильно”. Перейдем к “неправильно”.

Сразу переходите к сути.

Есть такой термин User Story в Agile/Scrum. История отличается от конкретной задачи определенным уровнем абстракции и отсутствием технического контекста. Условная история выглядит так: “Как пользователь портала я хочу иметь кнопочку, которая будет показывать мне корзину в всплывающем окошке”. Как видите - никакой конкретики. Ни где должна быть расположена эта кнопочка, ни какого она должна быть цвета, ни надо ли показывать фото товара во всплывающем окне.
Такие задачи должны проходить через менеджера проекта или банду аналитиков, которые на выходе нарисуют конкретное ТЗ. Stakeholder (условно заказчик) не должен давать ничего больше, чем видение конечного результата. Мало того, заказчик не всегда знает, чего он хочет (что НОРМАЛЬНО), и это работа исполнителей превратить входную информацию в конкретную задачу через общение с ним.

Постарайтесь на самом деле понять, что они говорят.

Один вопрос - почему? Почему конечный пользователь продукта должна понимать технический сленг? Почему владелец продукта должен видеть разницу между jQuery и GraphQL? Если заказчик обладает такими же техническими компетенциями, что и разработчик, то зачем вообще нужен разработчик? На моей памяти разработчики, козырявшие техническими терминами на встрече с бизнесом, хотели потешить своей ЧСВ. Таких надо гнать, не задумываясь (Skilled assholes хуже рака).

Признайте, что они умнее вас (а они умнее).

На моей прошлой работе напрямую с разработкой работали менеджеры по продажам. Они ставили им прямые задачи по функционалу и следили за конечным результатом (этакое acceptance тестирование). Разработчики у нас были высшего разряда, профессионалы, окончившие бауманку и мехмат МГУ. Означало ли это, что они разбирались в торговле и управлению рисками на рынке commodity лучше “продажников”? Никак нет. Делало ли это продажников умнее разработчиков? Тоже нет. Коммуникация, построенная на модели “я умный, ты дурак” обречена на провал, вне зависимости от того, с какой стороны она исходит.

Дальнейший разбор будет позже. Надо и работать иногда. 😉