IT АНАЛитика | Вильд Виктор

Кто ты сегодня — джун, мидл или сеньор?

Когда меня на работе кому-то представляют:

«Это Виктор, он у нас сеньор»,
я каждый раз немного смущаюсь.

С одной стороны приятно (они ведь реально так думают, и не просто так).
С другой неловко.
Не потому что синдром самозванца, а потому что у каждого своё понимание, кто такой senior.

Всегда найдётся человек, который может спросить:

— «А ты делал задачу X на технологии Y для проекта Z, на 100500 пользователей, в условиях невесомости, с закрытыми глазами и на горящем стуле в поезде?»
— «Не делал, да?»
— «Тогда ты не сеньор. Ты чмоня, лох, позор компании и своих родителей. За что тебе вообще платят? Иди в 1С»

Вот поэтому я не люблю разбрасываться громкими словами.
В целом да, сеньор. Что-то знаем, что-то умеем, где-то работали😎.
Но без фанатизма.

Я понимаю, что в рамках корпоративной культуры нельзя просто сказать вместо senior:

«Это чувак, который лучше всех шарит».

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

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

Реальный пример: парень из Тбанка, сеньор-аналитик, пришёл на собес в Озон.
И там ему говорят — ну максимум джун+.
Те же скиллы, тот же опыт, просто другая культура и другие ожидания.

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

В разных проектах, конечно, свои особенности и требования, но я бы остановился на таких интерпретациях:

1️⃣Джун — неумёха, который хочет расти и развиваться.
Есть базовое понимание вещей, но не хватает опыта и практики, чтобы выполнять задачи самостоятельно.

2️⃣Мидл — уже многое умеет, владеет основными навыками и знаниями,
но иногда сталкивается с задачами, где без помощи будет тяжело.

3️⃣Сеньор — может с любой задачей справиться самостоятельно и без помощи.
Тут даже не обязательно дело в хардах.
Просто если перед ним появляется что-то новое и незнакомое он спокойно разберётся, быстро вникнет в суть и выдаст отличный результат.

А у вас как в команде или компании определяют, кто сеньор, а кто ещё нет?

IT АНАЛитика | Подписаться

HAProxy: зачем это знать аналитику?

Если вы работаете с высоконагруженными системами или микросервисами, то наверняка слышали где-то в чате или от своих разработчиков фразу:
«Что-то с хапрокси».

Пугаться не стоит давайте разберёмся.

🧠 Что такое HAProxy?
HAProxy (High Availability Proxy) - это программный балансировщик нагрузки и обратный прокси (reverse proxy).
Скорее всего, вы слышали про NGINX - это примерно то же самое, только со своими нюансами.

Он получает входящие запросы от пользователей (например, с фронта или внешних систем) и распределяет их по backend-сервисам.
То есть он как диспетчер на перекрёстке: стоит между клиентом и вашими микросервисами и решает, куда направить трафик.

Зачем он нужен?

➡️ Балансировка нагрузки
Когда есть несколько инстансов сервиса, HAProxy распределяет трафик между ними.
Это повышает надёжность и масштабируемость.

➡️Отказоустойчивость
Если один из серверов упал, HAProxy уберёт его из списка доступных и продолжит работу без сбоев.

➡️ Роутинг по условиям
Можно настроить маршрутизацию по URL, HTTP-заголовкам или другим параметрам.

➡️ Безопасность и контроль
HAProxy умеет ограничивать частоту запросов, блокировать IP и логировать обращения, что удобно для аудита.

Почему это полезно знать аналитику?
Ты не будешь его настраивать, но понимание принципа работы поможет:

✅ Быстрее понять, где может быть ошибка
✅Говорить с командой на одном языке (и даже с умным видом сказать: «ну я так и думал»).

Пример: если запрос с фронта "не доходит до backend'а", и тебе говорят, что "проблема где-то в HAProxy", то ты уже не паникуешь, а понимаешь, что это может быть связано с конфигом, правилами маршрутизации или падением одного из backend'ов.

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

📣 А вы сталкивались с HAProxy в своих проектах? Или вообще с балансировщиками?

IT АНАЛитика | Подписаться

Главное не забыть стоп слово🍑

P.S. Для тех, кто недавно подписался: задолго до аналитики я работал в техподдержке.
И с тех времён у меня осталась куча забавных историй от пользователей.

Похихикать можно по тэгу #поддержка

IT АНАЛитика | Подписаться

Подборка шаблонов для аналитика

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

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

Для ведения документации на проекте
Общий для заведения задач на разработку
Для оформления бизнес требований
Для оформления системных требований
Для принятия от бизнеса задач в работу
Для документации к микросервису
Для функциональных требований (фронтенд)
Для описания методов

А какие шаблоны есть у вас?

IT АНАЛитика | Подписаться

В прошлом посте умные люди подсветили важный момент:
у GET метода не может быть тела запроса.

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

В чате разработки начался сущий кошмар, когда они увидели этот метод

Я видел однажды, как он убил прод… методом.

В Джоне Уике (2014) Киану Ривз убил троих карандашом, но только не методом /GET и не на проде.
У нас же «оружием» иногда становится плохо описанный метод, который может завалить проект ничуть не хуже🤯.

Какие есть подводные?

1. Неясные входные параметры
Аналитик не указал, какие поля обязательные.
На проде метод вызывают без нужного параметра → упали.

2. Неопределённые типы данных
Ожидали int, прилетел string → через некоторое время приходит баг.

3. Нет описания ошибок и кодов ответа
Метод возвращает какой-то ответ, но без описания.
В итоге каждый понимает его по-своему.

4. Логика описана не полностью
Запись не найдена, сервис вернул пустой ответ, превышен лимит и т. д.
На проде это превращается в зависший UI или кривые данные.

5. Нет ограничений по производительности
Не уточнили, что метод должен отдавать максимум 50 записей.
Фронт запросил все транзакции клиента (500 строк) → таймаут, нагрузка, сервер лёг.

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

А у вас как описывают методы в проектах?

IT АНАЛитика | Подписаться

У кого жиза?


IT АНАЛитика | Подписаться

Ещё немного про работу с текстом

Если в прошлом посте я писал про микро-статьи по работе с текстом, то вот ещё одна простая штука, которая реально помогает.
Есть сайт — Главред. Через него можно быстро проверить текст на «воду» и понятность.

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

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

IT АНАЛитика | Подписаться

Я уже писал про PlantUML.

Но если вы всё ещё чертите схемы от руки или в PowerPoint, то вот одна из инструкций на тему, как начать пользоваться им на практике:
Читать📚

IT АНАЛитика | Подписаться

Мы писали, мы писали, наши пальчики устали…

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

Чаще всего задачи валятся именно на нём.
Описал абы как → разработчик сделал «как понял» → баги на проде и жалобы от бизнеса.
В итоге команда и бизнес получают не то, что нужно, а TTM только растёт.

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

Рекомендую добавить в закладки и пройти хотя бы пару уроков.
Команда и бизнес потом скажут спасибо.

IT АНАЛитика | Подписаться