Знаете какая самая популярная метрик в SaaS бизнесе?

ARR (Annual Recurring Revenue). Это когда вы продаете продукт по подписке (subscription), где клиенты могу платить по месяцам. То есть, если купили ChatGPT за 20$ в месяц, то ARR будет 12x20=240$. Конечно, там всякие нюансы, про годовую vs месячную подписку, B2B vs B2C, модели ценообразования и тп, но это прям must have domain knowledge. Есть еще и MRR, ну вы поняли:)

Но пост-то не про это😜

Обычно когда мы в найме, мы работаем за зарплату. Зарплата может быть gross/net, за месяц/за год. Но ключевое слово зарплата, где мы ощущаем себя наемными (то есть легко заменимыми) рабочими, которых хотят заменить то ли AI, то ли дешевой рабочей силой из Индии (применимо для западного мира). Вот и живем в такой парадигме найма, часто мучаемся от burnout, mental health pressure, панические атаки из-за риска потерять работу и далее по списку психологических расстройств modern workforce, то есть нас.

А что если, поменять парадигму? Мы работаем не за зарплату, а у нас бизнес, и наша зарплата, которую нам платит работодатель клиент это на самом деле ARR, вы у нас (или нас самих) купили по подписки, чтобы мы делали работу, то есть нам нужно считать ARR (это gross доход). Тогда и клиентов и доходов может быть больше одного (ваши side проектики, консультации и тп).

В таком случае вы не будете ныть, что у вас плохой performance review или вам не подняли зп, вы думаете в контексте клиентского опыта, где доход зависит от качества оказываемых вами услуг. Причем, услуг не технических (с hard skills обычно не бывает проблем), а услуг связанных с soft skills.

Тогда риск burnout и других ментальных расстройств сокращается, доход возрастает (ребята в Surfalytics не дадут соврать), job security как таковой уже не главная проблема, если человек все время учится и в режиме grow mindset и вместо утренней зарядки идет на собеседование (на всякий случай). С таким подходом качество работы возрастает, ведь если инженер или аналитик думают о своих проектах на работе как о личных проект, думают о “клиентском опыте” работодателя и своего менеджера, то все действия будут направлены на повышения этих метрик, что в конечном итоге приводит к повышения ARR.

Я больше не использую слово зарплата, мне важен мой ARR и факторы которые на него влияют.

Мы прилетели утром в Париж, чтобы посмотреть финал Tour de France. Шёл небольшой дождь, центр города был перекрыт, но это никого не смутило - все пришли поддержать спортсменов и почувствовать атмосферу великого события.

Вот несколько интересных фактов о Tour de France (я попросил chatgpt рассказать про основные идеи гонки):

🚴‍♂️ Что такое Tour de France?
Tour de France — это крупнейшая и самая престижная многодневная шоссейная велогонка в мире. Она проводится ежегодно во Франции (иногда частично затрагивая соседние страны) и собирает лучших велогонщиков планеты.

📆 Когда она началась?
Первая гонка прошла в 1903 году, её организовала газета L’Auto для повышения продаж. С тех пор она проводится почти каждый год, с перерывами лишь во время мировых войн.

⏱️ Сколько длится и когда проходит?
Tour de France длится около 3 недель, традиционно в июле. В 2025 году гонка стартовала 5 июля и завершилась 25 июля — финишом на Елисейских полях в Париже.

🏔️ Какие испытания входят в гонку?
Гонка состоит из нескольких этапов (обычно 21), включая:

Равнинные этапы — для спринтеров
Горные этапы — в Альпах и Пиренеях, для горняков
Индивидуальные гонки на время (тайм-триал)
Командные этапы
Гонщики соревнуются не только за общее время, но и в различных категориях.

💰 Сколько стоит велосипед?
Профессиональный шоссейный велосипед для Tour de France стоит в среднем от 10 000 до 15 000 евро, иногда и дороже. Главное условие — велосипед должен быть "стоковым", то есть доступным на коммерческом рынке (в рамках правил UCI), без секретных или запрещённых модификаций.

🏆 Как определяют победителя?
Победителем общего зачёта становится гонщик с наименьшим суммарным временем по итогам всех этапов. Помимо главного зачёта, есть и другие:

Очковый зачёт (зелёная майка) — для лучших спринтеров
Горный зачёт (в гороховую майку) — для лучших горняков
Молодёжный зачёт (белая майка) — лучший гонщик до 25 лет
Командный зачёт

🟡 Почему жёлтая майка?
Жёлтая майка (maillot jaune) — символ лидера общего зачёта. Цвет выбран в честь бумаги, на которой печаталась газета L’Auto — организатор первой гонки (бумага была жёлтой).

🥇 Кто победил в 2025 году?
Финальный этап Tour de France 2025 завершился 25 июля на Елисейских полях в Париже.
Победителем этапа стал Jasper Philipsen (Бельгия, Alpecin-Deceuninck) — один из лучших спринтеров современности.
Победителем общего зачёта стал Tadej Pogačar (Словения, UAE Team Emirates) — он выиграл Тур уже в третий раз (после побед в 2020 и 2021 годах).


Вот два хороших видео:
- Tour de France Explained For Newbies (тут как раз рассказывают про все, что выше)
- TOUR DE FRANCE 2025 – HISTORIC! Van Aert breaks Pogacar and triumphs on the Champs‑Élysées (про сегодняшний заезд)

Что еще рассказать? Есть интересный канал Михаила Иванова (одного из основателей издательства МИФ), он часто пишет про триатлон и велогонки, проводит велотуры в Европе и США и участвует в мировых триатлонах. Недавно он рассказал, что можно наслаждаться всей красотой горных поездок на элетро-велосипеде, реально game changer. Возможно в будущем я смогу поучаствовать в таком туре. Вообще хотелось бы взять саббатикл и просто несколько месяцев колесить по Европе без цели.
А еще Михаил много пишет про инвестиции и я у него покупал курс по инвестициям, который мне очень понравился, на котором мне простым языком рассказали какие инструменты существуют и как важно балансировать портфель.

В больших корпорациях есть методология выявления сотрудников с высоким потенциалом. Некоторые изобретают свою, некоторые по ощущениям, а кто-то берет готовый фреймворк, как например в статье The Ultimate Guide to High‑Potential Identification

В статье рассказывают про HiPo сотрудников (high‑potential) - это сотрудники с высоким интеллектом, стремлением к росту, гибкостью и лидерской направленностью, способные эффективно справляться с более сложными ролями в будущем.


При оценке сотрудников учитываются такие признаки:
- Стратегическое мышление
- Стремление к совершенству
- Обучаемость и адаптивность
- Умение принимать решения
- Проактивность и инициатива
- Ориентация на руководящие роли
- Построение отношений и управление заинтересованными сторонами
- Комфорт при работе в условиях неопределённости или изменений

Популярные инструменты для оценки HiPo:
- Assessment & Development Centers (ACDC) - виртуальные, традиционные или смешанные центры оценки с ролеплеями, симуляциями, интервью, тестами
- 360‑градусная обратная связь - отзывы от самих сотрудников, коллег, подчинённых и клиентов как инструмент анализа потенциала
- Assessment‑тесты - краткие стандартизованные тесты на личность, когнитивные способности, обучаемость; подходят для больших групп и начальных уровней

К сожалению здесь большую роль играет человеческий фактор. Из инструментов я использовал 360-градусов обратную связь.

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

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

Для контекста. Из компании Газпром-Медиа уволили накрутчика опыта, который работал над Rutube. Сотрудники службы безопасности нашли отзыв, который он оставил год назад, где рассказал, что накрутил опыт. Накрутчик работал в компании около года. С его перформансом всё было в порядке. Он готовился идти на повышение.

То есть ещё раз: нормально работающего сотрудника уволили за то, как он попал в компанию год назад.

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

В Газпром-Медиа запущено так называемое «дело волков» (я не шучу, они сами так его называют), людей водят на допросы в службу безопасности, где светят лампой в лицо.

Охранительная часть IT-комьюнити рукоплещет Газпром-Медиа за такую инициативу. Глеб Михеев написал:

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

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

Сам Глеб занимал пост «Директор по развитию образовательной платформы» в Skillbox. Работа там, кстати, на репутацию не влияет. Skillbox всего лишь оставил тысячи людей с кредитами, не дав ничего взамен. А вот подписка на «ОМ» — это клеймо на репутации.

Зачистку же внутри Rutube проводит ещё один моральный камертон отрасли, Head of Client Development в Rutube, Максим Ульянов. На скриншоте его сообщение из внутреннего рабочего чатика. Давайте представим, что институт репутации действительно есть. А вы работаете в государевом видеохостинге, который существует из-за двух причин: распилить гос. бабки и отрезать граждан собственной страны от информации. Плюсом, Rutube — рассадник пиратского контента. Но вы не перепутайте, у Максима репутация просто прекрасная, а вот у подписчиков «ОМ» — нет.

Максим и Глеб, очень хорошо учить других жизни и говорить про репутацию, когда у самих рыльце в пушку. Репутации в IT нет, и вы вдвоём — выгодоприобретатели этого. Потому что если бы она была, то первой бы ударила по вам.

Обращаюсь к обоим, вы публично призываете к тому, чтобы лишить возможности работать огромную группу людей просто по факту подписки на ОМ. Приходите ко мне на канал для дебатов с Антоном. Можете по одному, можете вдвоём. Я готов предоставить площадку для дебатов. Антон дважды дебатировал у меня на канале, от обоих оппонентов Антона ко мне не было нареканий по модерации. Если не принимаете предложение, то жду публичного ответа.

Как любил говорить мой любимый учитель английского в лицее №1501: «Когда одним хорошо, другим дурно».
Когда читаешь истории о людях, которых увольняют из-за ерунды, становится грустно. Если бы я сам всегда был честен, не уверен, что смог бы перейти с завода ГКНПЦ им. Хруничева в Cetelem (BNP Paribas). К сожалению, у меня не было ментора, который мог бы подсказать, что учить, что говорить. Первые три месяца я вообще работал бесплатно.

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

А теперь представим: вы захотели работать в ИТ, но у вас нет профильного образования и опыта. Что делать? Заплатить 150–250 тысяч за псевдокурсы с обещаниями трудоустройства? Или смириться и пойти в курьеры?

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

Из подобных историй видно: процессы найма кривые, а некоторые менеджеры — самовлюблённые, без реальных заслуг, с посредственной жизнью. Такие пытаются самоутвердиться за счёт подчинённых. «Максимов» и «Глебов» хватает везде — и не только в отечественных компаниях. Обижаться на них не стоит — скорее всего, у них в жизни всё непросто и нечем гордиться.

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

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

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

Интересная статья про отрицательную селекцию

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

В посте товарищ указал на некоторые из проблем, с которыми он столкнулся:

Я работаю с технологией Snowflake уже 7 лет, и вот вещи, с которыми большинство внедрений Snowflake сталкиваются и с большим трудом справляются.
- Role-based access control — Очень легко создать полный хаос, после чего команда DBA оказывается навечно занята решением проблем с доступами.
- Virtual Warehouse deployment — В итоге у вас появляется сотни VW, и расходы стремительно выходят из-под контроля.
- Data Clustering — Они не работают как индексы и часто приводят к огромным затратам без какого-либо прироста производительности.
- Migrating to Snowflake — На первый взгляд кажется, что это намного проще, чем миграция на Oracle (или с него), но затем вы понимаете, что Snowflake сильно отличается — а миграции баз данных вообще всегда болезненны.
- Performance vs. Cost — В Oracle или SQL Server вы раньше просто тюнили производительность. В Snowflake же у вас три конкурирующие задачи:
- (a) Performance — как можно быстрее выполнять пользовательские запросы
- (b) Throughput — обрабатывать огромные объёмы данных, т.е. буква T в ELT
- (c) Cost — о которой вы даже не задумываетесь, пока менеджеры не начнут жаловаться, что система обходится в миллионы долларов в год.

Про RBAC полностью соглашусь, я использовал и Terraform, и permifrost, но в больших конторах всегда все выходило из под контроля и любые изменения занимают время + ограничения каждого из подходов.

Цена у Snowflake всегда боль. А с тюнингом не заморачиваются, просто увеличивают размер VW или кластера.

Альтернативы всегда есть, но как всегда в ИТ это tradeoff.

Какая мораль истории? Во всех аналитических проектах, даже если там не Snowflake, всегда важна безопасность, цена и производительность. Именно на этом и нужно акцентировать внимание при работе и собеседованиях.

Data Observability относится к data engineering, и является его неотъемлемой частью, согласно best practices, конечно.

У меня давно в закладках лежит статья - SLA vs SLO.

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

📌 Зачем вообще всё это нужно?
SLA, SLO и SLI — это инструменты управления надёжностью сервисов. Они помогают установить понятные и измеримые ожидания между теми, кто предоставляет сервис (разработчики, команды, компании), и теми, кто его использует (внутренние или внешние клиенты).

💡 Основные термины:
SLI (Service Level Indicator) — Показатель уровня сервиса: метрика, которая показывает, насколько хорошо работает сервис с точки зрения пользователя (например, доступность, время отклика, процент ошибок).

SLO (Service Level Objective) — Целевой уровень сервиса: цель по метрике (например, “доступность 99.9% за 30 дней”). Если сервис ниже цели — это тревожный сигнал, может остановиться деплой, пойдут расследования.

SLA (Service Level Agreement) — Юридическое соглашение об уровне сервиса: официальный контракт, в котором закреплены SLO и последствия их невыполнения (штрафы, компенсации). Обычно используется во внешних отношениях с клиентами.

🤝 Зачем это нужно:
Командам — чтобы знать, когда сервис работает плохо и нести ответственность.
Бизнесу — чтобы договариваться с клиентами на чётких условиях.
Пользователям — чтобы понимать, на что можно рассчитывать (и требовать компенсацию при сбоях).

🧭 Простая аналогия:
SLI — это стрелка на спидометре.
SLO — это знак "не ехать быстрее 100 км/ч".
SLA — это штраф за превышение.

Практически на всех проектах по инжинирингу данных обсуждается тема мониторинга, но очень редко мы действительно устанавливаем метрики, ведь в большинстве случаев аналитика и хранилище данных это не business critical приложение, и если что-то сломалось, то мы можем починить в течения дня. Хотя было бы неплохо установить SLO для бизнеса, что хранилище данных и отчетность будет доступна 99% в течение рабочего времени. И даже если это не соответствует действительности, мы можем установить начальную точку и двигаться в сторону улучшения. Как правило у нас SLA не будет, да и SLI тоже не обязателен.

А есть совсем другой пример, когда компания продает данные американских клиентов (их обезличенные гео данные на млн долларов) в другую компанию, которая находится за пределами США. Эта компания, использует данные для классической аналитики трафика людей в разных городах. Так как компания платит большие деньги они установили SLO и SLA. И в случае сбоев выставляют штрафы. Из недостатков такого проекта для дата инженеров - on-call.

SLI (Service Level Indicators) — метрики, которые мы измеряем:
unique_user_count - Кол-во уникальных пользователей в часовой выгрузке
event_volume_total - Общее кол-во событий в часовой выгрузке

SLO (Service Level Objectives) — цели по этим метрикам
unique_user_count - > 90% от среднего значения за 4 недели
event_volume_total - > 90% от среднего значения за 4 недели
data_delivery_lag_minutes - < 10 минут задержки 99% времени
data_integrity_flag - 100% данных доставлены без ошибок 98% времени

SLA (Service Level Agreement) — договор с клиентом, в котором
- Фиксируете SLO (например, 98% своевременных поставок в течение месяца)
- Описываете последствия (например, штрафы, перерасчет, SLA-кредит)
- Уточняете исключения (форс-мажор, проблемы на стороне клиента)
- Описываете процесс эскалации и ответственности

Пример SLA-формулировки:
Мы гарантируем доставку данных каждый час в течение 10 минут после окончания часа. Минимально допустимый объем — не менее 90% от среднего за предыдущие 4 недели. Если в течение календарного месяца нарушены более 2 SLA-интервала, предоставляется SLA-кредит 10% от месячного счета.

Цифры SLA у нас в договоре другие, метрики такие как я указал.

Само решение достаточно не сложное, данные все хранятся в AWS S3 в Parquet. Другая команда использует kinesis и пишет в S3. Данные каждый час обрабатываются с помощью Athena и запускается в Glue Python Shell (даже не PySpark). Результат складывается в другой S3 bucket и дальше он проверяется с помощью другого Glue Job. Все метрики публикуются в Cloud Watch.

Cloud Watch подключен через SNS topic к Pager Duty, и в случае отклонения получаем alert в Slack. Сейчас решение мигрируется в Databricks, таблицы переходят с Parquet на managed delta tables (Parquet + Delta log). Для проверки качества данных используем DBX библиотеку. Самое забавное, цена в Databricks получается значительно дороже, чем в Glue Athena. В качестве оркестратора AWS Managed Airflow.

MWS Cloud запустила платформу для внедрения и работы ИИ, выйдя на рынок объемом более 15 млрд рублей.

Платформа Inference Valve помогает вывести в продакшн обученные ML-модели, большие языковые модели и модели компьютерного зрения. С помощью платформы их можно разворачивать на инфраструктуре, подключать к ИТ-системам компаний через стандартные API, масштабировать, а также обновлять и мониторить.

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

Inference Valve также предоставляет метрики задержек и пропускной способности, мониторинг доступности, алёрты и дашборды; доступна телеметрия качества, включая отслеживание дрейфа данных и моделей, контроль целевых метрик и уведомления при деградации. Интеграция с системами наблюдаемости (Prometheus/Grafana) и журналированием запросов упрощает аудит и разбор инцидентов.


По словам CEO MWS Cloud, исполнительного директора МТС Web Services Игоря Зарубинского, платформа позволяет:

- В десятки раз быстрее интегрировать LLM и CV-модели с ИТ-системами компаний;

- На 70% снизить операционную нагрузку на ML-команды при эксплуатации моделей;

- Повысить автоматизацию CI/CD более чем на треть;

- Уменьшить затраты на GPU более чем на 15%;