Google Cloud

Продолжаем наши #полезняшки

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

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

Милая деталька: в отличии от остальных, у гугла нет странички с описанием free tier на русском языке

Итак, гугл предлагает нам все примерно тоже самое: микроинстанс, доступ к БД, S3 и лямбды, а также интересная фича: облачная IDE

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

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

А еще они дают 300$ на "поиграться" новым пользователям. Вот здесь все описано подробно

Возвращаясь в реальность

Собеседовал недавно человека на позицию девопса. Ищу человека себе в команду для довольно приземленных задач. И вот человек мне говорит:
— Я yaml-ы писать не хочу, это вот совсем не мое. Я вообще офигенный разработчик и хочу писать на расте для linux kernel. Или какие-нибудь крутые инфраструктурные штуки делать. Но я особо не умею и поэтому ищу того, кто меня научит

Я, честно говоря, сначала охуел прилично. А потом спрашиваю: А в чем твоя ценность для бизнеса, как инженера? Что ты вообще можешь дать, какое value принести в команду и процесс?
И он начал мне рассказывать какие крутые проекты он делал, какие прям вот сильные вещи писал.
Не понял, в общем, вопроса. Окей, продолжили. Работает он сейчас в Mail.Ru. Говорю. ну вот Мейл делает tarantool, крутой проект же. К тому же в опенсорсе. Что ты к ним в команду не попросишься?
— Не, отвечает, тарантул мне не нравится. Код там говно, lua еще эта сраная, и вообще, еще один key-value не нужен, есть клевый etcd, там raft, алгоритмы консенсуса и все такое, это я люблю.
(про использование тарантула как application server-а с офигенно быстрым kv на борту он, видимо, не подумал)
— Ну так сделай его клевым, — говоря ему я, — почему бы и нет?
— А я на сях не умею! Да и не хочу. Вот раст круто, я хочу писать на расте для Linux kernel
— Ну хорошо. Пусть так. А ты пробовал вообще что-нибудь для ядра писать? Вон доков в сети навалом (мне было интересно его мнение про дизайн Kernel API)
— Не, я не пробовал ничего. Не могу придумать, что написать. Все уже написано🤷‍♂️

Хорошее интервью получилось.

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

Infrastructure as Software

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

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

Так появились agile-методологии, devops-практики, тут пропустим большой пласт истории, каждый желающий может найти по этой теме сотни статей на том же хабре и придем к тому, что мы имеем сейчас: у нас есть кубернетес, эдакий новый стандарт в индустрии, умеющий вообще все, что связано с запуском любых приложений. Имеет в основе своей декларативный формат описания своих сущностей. И их у него там не одна или две, а прям дохера, густо сплетенных между собой. И помимо базовых встроенных примитивов кубернетеса есть возможность писать свои, так называемые Custom Resource Definitions, что уносит количество примитивов прямо-таки в облака. Для тех же операторов кубера уже есть цельный отдельный "хаб". В итоге мы имеем пачку yaml-ов, огромное количество неочевидных связей между ними и какую-то логику их применения. Круто, можем положить это в гит и иметь версионирование, git blame и все вот это, что мы так любим.

Дальше у нас есть некий нижележащий слой условного железа, который в современной cloud-native среде превращается все равно в теже выделяемые провайдером ресурсы, которые надо бы как-то сначала сконфигурировать. Ну и плюсом у вас, например, не только кубернетес, а еще и какие-то ресурсы рядышком. Нужен Configuration Manager, который автоматом развернет и сконфигурирует приложения, да и тот же кубер например. Берем Ansible и получаем еще один набор ямликов, который описывает первичную конфигурацию всего нашего хозяйства. Ну и логику их применения конечно. Ах да, плюсом ансибл не знает ничего про состояние и в этом моменте его декларативность сыплется и нам уже нужно добавлять какую-то императивную логику, дабы все не порушить к херам. Но да, опять все положим в гит, потому как это все текстом описано удобненько

Но Ansible не может "заказать" ресурсы у провайдера, а может только работать уже с готовыми. А если вы оперируете сотнями инстансов VM у разных провайдеров (а VM, ну точнее Compute Node, например, все еще является базовым примитивом у облачного провайдера и никуда от них не деться), то человеческий фактор довольно быстро смачно даст вам под дых и превратит семейный субботний вечер в debugging hell. Нам на помощь приходит Terraform, приносит с собой свой собственный декларативный формат описания состояния, умеет получать информацию об этом состоянии прямо-таки вот из первых рук и вообще, очень хороший и удобный инструмент. Основную движущую силу которого, tf-файлы, также можно хранить в гите. Ну и иметь некую логику их применения.

И вот мы подошли к самому интересному. У нас есть гит как источник истины (Single Source of Truth), есть наша платформа, которая видоизменяется в соответствии с изменениями в нашем SSoT и есть инструменты, которые синхронизируют эти две сущности (GitOps, Infrastructure as Code и все такое). И вроде все кайфово и хорошо, но! Кто-то должен класть деньги в тумбочку. То есть эти ямлики в гит. И вот тут мы получаем развесистую пощечину и специальность "yaml-инженер". И я не шучу. Дело в том, что вот вся эта декларативная куча 💩 должна как-то управляться, а в силу декларативной природы, реализации логики в ней нет. А есть она в голове у инженера.

И люди начали задумываться о том, что управлять этим всем очень непросто и мы опять наворотили непомерно сложную махину в погоне за простотой. И хорошо бы наши декларативные описания и логику их применения не разносить по разным сторонам (гит и голова инженера), а таки стащить их в сторону гита и генерировать все автоматом, не занимаясь программированием на конфигах. А заодно понизить порог вхождения и повысить bus factor. А так как программированием все равно заняться придется, то и нечего выеживаться. Ну и в итоге мир стабилизировался. DevOps-ы садятся и пишут императивный код, генерирующий прекрасный декларативный мир, описывающий инфраструктуру. И получаем мы именно то, о чем написано в заголовке. Инфраструктуру как самостоятельное ПО. И сейчас оно довольно простое и даже выглядит решением проблемы. Как выглядел этим самым решением каждый шаг, пройденный инженерами и описанный в этом посте. Вангую, пройдет лет 5 и мы будем спорить об инфраструктурных фреймворках, которые под капотом будут управлять тысячами декларативно описанных сущностей, уже не поддающихся пониманию человеком.

Heroku

#полезняшки продолжает очередная платформа, позволяющая вам захостить свой пет-проджект без нанесения ущерба бюджету. "Большую тройку" с кучей сервисов мы уже разобрали, теперь поговорим про ребят попроще, но все равно довольно больших. Сегодня у нас на прицеле Heroku

Heroku — это PaaS, предлагающий вам доступ к небольшому, но очень полезному набору инструментов и также имеющий бесплатный тариф "на поиграться". Впрочем, начальные опции там тоже очень недорогие, если вы вдруг решите расти именно на Heroku

Итак, что мы получим на халяву?

До 1000 dynos, так в Heroku именуется их собственное решение для контейнеров, именно в них запускается ваше приложение. Будьте осторожны, контенйер будет погашен автоматически, если в течении 30 минут к приложению в нем не будет обращений. Имеет смысл периодически дергать ваше приложение какой-нибудь внешней пинговалкой (хоть с вашего домашнего компа, если он работает постоянно)

Managed Postgres c ограничением на 10К строк

Managed Redis (20Mb RAM и 20 коннектов)

Managed Kafka (7 дней хранения данных и 4 гигабайта)

И кучу аддонов на все случаи жизни

Также Heroku поддерживает так называемые Buildpacks — это инструменты для запуска приложений, написанных на различных ЯП, в рамках Heroku

Для управления вашим сетапом вне Web UI Heroku имеет удобную утилитку

Как видите, богатство выбора не такое как у "Большой тройки", но и пафоса поменьше :) Отличный выбор, чтобы покрутить своего пета

Чеклисты

Чеклисты — это очень крутая тема, незаменимый помощник в процессах, при исполнении которых нельзя что-то проебать. Человеческий фактор всегда будет вашим противником. И неважно, кто будет выступать источником этого фактора: ваши коллеги, подрядчики, сотрудники или вы сами. Законы Мерфи работали и всегда будут работать: если что-то может пойти не так, оно обязательно пойдет не так.

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

Это очень хорошая и полезная практика. Если вам необходимо выполнить какой-то очень ответственный процесс, потратьте два часа и составьте чеклист, вставляйте туда самые очевидные пункты, в момент "Х" вы можете про них просто забыть.

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

Чеклисты — это инструмент автоматизации в тех сферах, где нельзя воспользоваться программными средствами.

Воскресные развлечения. Обновляю систему с аптаймом в три с лишним года🤦‍♂️
Сервачок мой личный, как-то я подзабыл про него.
Заодно и проверим, насколько убунта переживет апдейт через два LTS-релиза. Буду обновлять до актуальной 20.04 LTS
UPD: пережила нормально :) Все сервисы запустились и работают. Были сложности с промежуточным обновлением до 18.04, а до 20.04 обновилась даже без ребута. Лайк👍
UPD2: Ну респект, кстати, диджитал-оушену. Больше 3 лет VM-ка у них проработала и ни единого разрыва, то бишь ребута. Мое уважение.

Разработка vs Эксплуатация

Начинал я вообще фронтендером :) Тогда это называлось HTML-верстальщик и писали мы на ванильном js, тогда даж жиквери еще не вышел на большую сцену и не перевернул мир. На дворе был 2003 год. Потом было много программирования, я писал на PHP, на перле, на сях, на джаваскрипте, на tcl даже и параллельно с этим изучал линуксы.

И в какой-то момент времени понял, что просто писать код мне неинтересно. Тогда (это где-то 2008 год) еще не было такого единения разработки и эксплуатации, devops только зарождался на западе и программисты просто коммитили свой код и тут же писали новый. Судьба уже написанного их волновала только тогда, когда код к ним возвращался с уже описанными багами. Я тогда много тусил с "большими ребятами", это badoo, яндекс и все вот эти чуваки, которые меняли правила игры в индустрии. И у них было много решений на уровне эксплуатации, которые меня прям поразили. Они придумывали что-то новое там, где, казалось, уже нельзя было ничего придумать. А потом кто-то привез концепции DevOps и все, мир для меня поменялся в сторону любви к инфраструктурным решениям.

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

В итоге я сформулировал для себя такой ответ. Мне субъективно интереснее эксплуатация потому что:

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

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

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

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

Возможность влиять на процессы across the company тоже очень драйвит. В матричной структуре компании инфра/девопс — это всегда сервисная горизонталь, которая взаимодействует со всеми продуктовыми командами и строить процесс деливери на этом уровне очень интересно.

Ну и челлендж, куда же без него :) Эксплуатация — это всегда сущность, которая только тратит деньги. Напрямую команда devops/sre не влияет на прибыль и поэтому я могу вносить свою лепту в revenue только двумя путями: уменьшать расходы и оптимизировать существующие процессы. Ну и следить за выполнением SLA конечно

Последние несколько лет я сместил фокус в сторону менеджмента, не только технического, но и people management, что не менее интересно. Причем я предпочитаю позицию "играющего тренера", не уходя далеко от ручного опыта. В менеджмент я полез исключительно затем, чтобы иметь возможность быть поближе к бизнесу и принимать решения на более высоком уровне, что всегда положительно сказывается на процессах и самочувствии моей собственной команды.

"А я еще я немножечко шью" 😁

Ngrok

Продолжаем #полезняшки теперь уже не платформами, а инструментом. Сегодня у меня на карандаше отличная тулза https://ngrok.com/

Инструмент не нов и достаточно известен и я с удовольствием расскажу про него. Ngrok позволяет зашарить любое приложение с открытым портом в интернет буквально в одно действие. Запускаете приложеньку у себя на локалхосте, например веб-сервер на порту 8080. Запускаете ngrok и говорите ему, что у вас на порту 8080 висит приложенька. Он в ответ выдает вам адрес вида http://d52ccfa03be8.ngrok.io/ и вуаля! Ваше приложение доступно через интернет. Незаменимая штука, когда надо по-быстрому зашарить кому-нибудь приложение с локалхоста. Ну или вебхук повесить какой-нибудь.

Из коробки есть SSL. У софтины есть свой собственный веб-интерфейс, живущий на 127.0.0.1:4040

Можно поднять несколько видов туннелей: http, tcp и tls. Соответственно, можно и ssh затуннелировать вполне, например

На бесплатном тарифе вам доступны 1 процесс online, 4 туннеля и 40 коннектов в минуту. Можно, кстати, даже без регистрации, но тогда туннель умрет через 2 часа

Для любителей поковыряться ручками и параноиков есть опенсорсная альтернатива, написанная на node.js: https://localtunnel.github.io/www/ Можно захостить у себя и также пробрасывать туннели одним движением. И не платить ничего за полный функционал🙂

Увеличение на порядок

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

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

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

​​Писательский блок

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

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

А потом мне пришла в голову одна очень простая вещь. Я подумал: "а зачем и для кого я вообще это делаю?" Зачем это лично мне и что я хочу выразить?
Выступить меня попросили друзья, это просто уважение к их просьбе? Нет, точно нет.
Это какое-то стремление к самореализации? Уже ближе, но все-таки тоже нет
Я хочу аккумулировать свой опыт и передать его в сжатом и понятном виде? Так, это уже очень близко
Я понимаю путь, по которому я прошел и хочу помочь пройти его тем, кто тоже решит это сделать. Вот оно, это отозвалось во мне максимально.

И писать стало легко, тезисы доклада и план будущего выступления прорисовались достаточно быстро.

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

"Создать шедевр легко. Просто стань совершенным и твори естественно"

VS Code в браузере

В сегодняшние #полезняшки попала совершенно чумовая, на мой взгляд, штука :)

Что получится, если скрестить 1С и гитхаб? Шутка, не тот 1С, о котором вы подумали. А просто добавляем к домену гитхаба 1s и получаем VS Code прямо в вашем в браузере, а в нем открыт тот репозиторий, который вы указали в URL

Пробуем https://github1s.com/kubernetes/kubernetes

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

Идея просто отличная, я считаю

Внутренний критик

В продолжение поста про писательский блок.

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

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

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

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

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

Продуктовые решения и инженерная культура

Поиск баланса между этими двумя понятиями — всегда очень сложное дело. Общих решений нет, все всегда упирается в частности.

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

На каких-то общих встречах при определении стратегии все выглядит хорошо. Все помнят про техдолг и про костыли, обещают дать время. Но когда дело доходит до реализации, то часто диалог выглядит так:

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

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

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

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

Приносите проблемы, а не задачи

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

Лучше всего расслабиться и принести именно проблему в ее исходном виде. И потратить усилия на то, чтобы объяснить, зачем именно мы это делаем и куда мы идем, а реализацию оставить на откуп тому, кто непосредственно будет это делать. На самом деле этим мы убиваем сразу двух зайцев: не тратим ресурсы на перекладывание информации из одной головы в другую, тем самым избегая ее искажения и повышаем мотивацию человека, который будет делать задачу. Люди чувствуют когда им доверяют и позволяют реализоваться как профессионалам и ценят это. От менеджера же требуется лишь доверять своим сотрудникам. Микроменеджеров никто не любит и эффективность ваших сотрудников будет падать

"К сервису заказов в корзине нужно добавить текстовое поле для промокода, а в базе сделать новую табличку с такими-то полями" — плохо

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

Тестовые задания

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

Код в статике никому не нужен, на гитхабе огромное количество хорошего мертвого кода. Главное в процессе — это развитие.

Автоматизация

Сегодня капитанский пост. Про автоматизацию.

Вкратце мой посыл таков: автоматизируй все, что можно

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

У меня в вакансии, кстати, есть пункт "понимать, почему не стоит ходить на сервера по ssh" и недавно один товарищ написал в отклике "все технологии, описанные вами. я готов изучить, но не понимаю, почему не стоит ходить на сервера по ssh"

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

Про nocode

Современный тренд на nocode-платформы меня прям умиляет. Я вспоминаю начало 2000-х и кучу CMS, которые должны были похоронить профессию программиста как факт. 15 лет прошло и до сих пор хоронят. Надо признать пару очевидных вещей: во-первых, из nocode-истории можно собрать только то, что задумал разработчик. Все хотят повторения чуда Lego, из которых реально можно собрать что угодно, но чуда не случается. А во-вторых, для использования nocode-платформ нужно быть технически подкованным человеком. Все истории успеха, все продукты, собранные на них, были собраны людьми, так или иначе имевших опыт в IT: разработчиками или админами.

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

Так что это очередной булшит, революции не произойдет

Часто очень мелькает вопрос: а как отличить миддла от сеньора? Как определить мой грейд?
Я для себя определил очень простую шкалу:
- джун не знает как делать
- миддл знает как делать
- сеньор знает как не делать

Не бывает больше одной срочной задачи

Это бессмыслица уже по своей форме даже, не только по сути. Всегда есть градация приоритетов. Вот, например, как это сделано в гугле. Задача уровня Р0 (то есть имеющая максимальный приоритет) критична для бизнеса и все ресурсы должны быть брошены на ее выполнение. У таких задач должно быть явно обозначенное время реакции и четко прописанный регламент. Команда не должна выбирать и думать, какая из Р0 приоритетнее🤔
Поэтому когда приходят два менеджера со "срочными" задачами, и это не бизнес-критикал, а просто горит, то надо понимать: либо будет сделана одна, но хорошо. Либо обе, но хуево.

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

​​Про рутину

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