Через пару минут — новая заявка: «Я под кроватью, по квартире кто-то ходит…»

Как там этот фильм назывался? А, точно — Паранормальная удалёнка👻.
#поддержка

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

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

Кто тоже в августе ходил в отпуск, ставьте класс

Посты
Запись эфира про требования, работу с ИИ и разные фреймворки
Про работу с согласованиями
Обратное собеседование компаний

Интересные статьи
Архитектура приложений и интеграции

Мемы
БУ, испугался?
Да, было
Перейти на главную страницу

#итоги_месяца

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можешь объяснить попроще? Мы стартап

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

Разговор был хороший, вроде не тупил, и, скажу честно, был сильно уверен в себе и рассчитывал на оффер💵.
Это был один из первых собесов по системному дизайну, я тогда ещё не прочитал ТУ САМУЮ КНИГУ.

Но потом пришёл вот такой ответ (картинка к посту).

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

Я раньше много собесов проводил, и как по мне, если кандидат уходит в детали, хорошо аргументирует и при этом всё говорит верно, то дальше уже ответственность интервьюера модерировать разговор и плавно переходить к следующей теме.

«Ок, мы видим, что ты тут шаришь, давай дальше».

Понимаю, стартапы часто ценят скорость.
Но в архитектуре, где речь идёт о деньгах и рисках,
умение думать системно, а не просто “написать решение” - это всё же плюс, а не минус.

А вы как считаете — что важнее на собесе: глубина или скорость? Делитесь в комментариях

🦄 — если детали важнее
🐶 — если скорость решает

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

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

На самом деле месяцЕВ, но сентябрь вышел чиловым, так что подведём итоги сразу за сентябрь и октябрь.
Что интересного было за это время:

Посты
Набор уроков, чтобы начать лучше писать текст
Сайт, через который можно прогонять свой текст на "воду" (удобно при описании задач)
Шаблон для описания методов
Подборка шаблонов для аналитика на каждый день
Про HAProxy aka балансировщик нагрузки
Про грейды в IT и их целесообразность
Как я сходил на собес в стартап в прошлом году

Интересные статьи
Одна из инструкций на тему, как начать пользоваться PlantUML на практике
Про работу кросс-функциональных команд по модели Spotify

Мемы
Бизнес спрашивает у аналитика за оценку
Настраиваем почту по принуждению

#итоги_месяца

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