Привет =) На связи снова Анастасия-аналитик из команды STM Labs со своей любимой темой «мягких» навыков. В статье про собеседования (первая часть тут, вторая тут) я сравнила аналитика с переводчиком с бизнесового языка на разработческий. Или наоборот.
Недавно у нас на работе произошел случай, на примере которого можно в шутливой форме раскрыть это сравнение и наглядно показать, почему же аналитику важно понимать, с кем он разговаривает, и как доносить одну и ту же информацию до людей с разными ролями в проекте.
Вторая часть масштабной статьи про собеседования. Первая — тут. В прошлый раз мы поговорили об идеальном кандидате в вакууме, а также о презентационной части собеседования. Здесь же будем говорить про техническую часть и про то, в каком направлении бы хотелось развивать тему с собеседованиями.
В конце добавила секцию с бонусными рубриками — советами и наблюдениями для тех, кто проводит собеседования или приходит на них как кандидат =)
Я работаю в компании STM Labs, где мы строим большие высоконагруженные системы класса Big Data. Эта статья написана по мотивам моего выступления на конференции Saint Highload 2023. Хочу рассказать вам увлекательную историю про то, как мы искали лучшее решение по синхронизации аналитического и оперативного хранилищ в реальном времени. Нам важно было сделать это без потерь, потому что на кону стояли сотни и более терабайт данных.
Сразу обозначу, чего в этой статье не будет:
• Я не буду подробно говорить о типах СУБД и их различиях. • Я не буду делать обзор аналитических СУБД. Тут каждый выбирает сам. • Я не буду подробно останавливаться на архитектуре, отказоустойчивости и масштабировании СУБД MongoDB. • Я не буду делать обзор отличий OLAP и OLTP. • Я не буду делать обзор и сравнение реализаций CDC в различных СУБД.
Про собеседования, аналитиков и не только, на различных IT и не очень ресурсах написано достаточно много. Но ведь это не повод не рассказать, как они происходят у нас — вдруг что-то новое для читателя да и проскользнет? =)
Сегодня речь пойдет о mediation-системах — системах обработки больших данных класса OSS/BSS (Operations / Business Support System). Они получают данные из разнородных источников, обрабатывают в зависимости от требований и передают в нужном формате в другие системы-потребители. Чаще всего их применяют в телеком-сфере: они собирают информацию об абонентском трафике, который условно можно разделить на две группы: голосовой и передача данных (интернет), преобразуют, а затем отправляют в биллинговую систему для выставления счетов. Поэтому такие системы называют предбиллинговыми.
Но их возможности также применяют для автоматизации в логистике, сфере коммунальных услуг или финансов. И вообще везде, где нужно собирать большие объемы разнородных данных, а потом в преобразованном виде отправлять в другие системы. В этой статье поговорим именно о телекоме, а в будущих я расскажу и про стриминг-платформы, и про интернет вещей, и про другие сферы.
Мечтал ли я когда-либо ворочать миллиардами? Честно признаюсь, да. И нельзя сказать, что Вселенная меня не услышала. Вот только я никак не имел в виду миллиарды записей в базе данных...
Ранее я уже писал о нашем опыте использования ScyllaDB в качестве архивного хранилища. Разумеется, исследования и открытия, связанные с новой базой данных, для нас на этом не закончились... Создавая архив для данных, вероятность обращения к которым близка к нулю, мы, конечно, допускали, что время от времени клиенты будут просить вернуть данные обратно в оперативное хранилище. Но запрос на извлечение из архива сразу всех записей стал для нас неожиданностью. Хорошо ещё, что клиента интересовал только ключ записи, а не вся запись целиком. Тем не менее достать 10 млрд. ключей из ScyllaDB за приемлемое время звучало как челлендж. Ну надо так надо.
Мы в STM Labs разработали ПроЧек — лучшее (конечно же, по нашему мнению) приложение для хранения и анализа чеков. ПроЧек все делает сам: автоматически загружает чеки, сортирует покупки с помощью ИИ и строит отчеты. А мы продолжаем его развивать и дополнять функциями.
В этой статье — список из пяти других приложений для чеков, которые мы нашли полезными: одни просто хранят чеки, другие следят за тратами, ищут скидки или помогают зарабатывать на кэшбэке.
Как системный аналитик может улучшить юзабилити проекта. Разбираем простые, но неприятные недоработки на примере китайских систем для поступления в ВУЗы.
За пару дней до выхода статьи эта же аналитик подговорила наших ребят участвовать в командном хакатоне. Результат не самый приятный — 38 место из 60. Однако, этот опыт, как и любой другой, не прошел даром (а еще был очень веселым).
В этой статье каждый участник команды поделится своим опытом и персональной рефлексией. Ну и лулзами, пойманными в процессе.
Раньше аналитиков звали разве что на хакатоны в составе команд. Но относительно недавно — наконец-то — стали появляться специализированные контесты и хакатоны для системных аналитиков. С 2021 года я ввязывалась в целых три: в первом заняла третье место, во втором седьмое, а в последнем — первое.
В статье расскажу, как этим летом прошел хакатон Sovcombank Challenge 2022. И порефлексирую, как не надо участвовать в соревнованиях.
Сегодня у нас — экшен, основанный на реальных событиях. Будем переобуваться в воздухе и на лету менять архитектуру высоконагруженной системы.
Действие разворачивается на базе очень большой track & trace системы класса big data. В ней давно откладывали переход на шардированную архитектуру хранилища. Поэтому главному герою предстоит справиться справиться со злом, пробудившимся в системе под нагрузкой: деградацией производительности, полкой по блокировкам и алертами о перегрузке.
В конце — как обычно, хэппи-энд. Наш герой бесстрашно меняет архитектуру решения на лету без downtime (DT) и обеспечивает штатную работу системы. Зло повержено, а отважный инженер купается в овациях!
Статья написана по мотивам доклада на конференции Saint Highload++ 2022. Если не хотите читать — можно посмотреть видео-версию выступления.
Привет, я Никита. Вообще я инженер интеграции. Но, похоже, судьба мне быть тревел-блогером.
В начале прошлого лета я пять недель работал в Конго. Как результат — статья «Как айтишнику выжить в Африке». Почитайте, там несколько лайфхаков, как вернуться живым.
В этом году работать я отправился в Австрию. Уже не Африка, но экстрима я ожидал не меньше: белому русскому гетеросексуальному мужчине в месяц Прайда в 2022 могут быть рады не все и не везде.
Предположим, вы в системных аналитиках недавно, например, на позиции джуна. Вы уже представляете, в чем заключается работа, и планируете развиваться в этой сфере. Еще с вами багаж общих IT-знаний, умение гуглить и/или грамотный ментор.Через какое-то время вы осваиваетесь в изначальном проекте. Но системная аналитика, как оказалось, штука очень интересная. Поэтому вы начинаете искать, во что бы еще вляпаться — в своей статье говорю про развитие soft skills. Случаи, когда базовых hard skills нет совсем, здесь не рассматриваются.
Короче, как жить и набраться опыта аналитику, когда почти научился жить и еще не сошел с ума!
Немного контекста о том, как возникло это исследование... В один из тех летних дней, когда на улице стояла ясная, солнечная, жаркая погода, когда стрижи быстро пролетали за окном, распространяя веселые звуки, мы закончили очередную задачу по проекту (в нашем проекте используется Python). Задача заключалась в получении различными способами (очередь, сервисы, файловая система и т.д.) входящих документов (JSON формат), обработке этих документов и сохранении обработанных документов обратно в JSON формате в архивную базу данных. Завершив кодирование и юнит тесты, мы выкатили решение на одно из тестовых окружений и стали ждать результатов. По функциональности решение работало отменно, но, оценив скорость работы решения, я задался вопросом, а можно ли его ускорить?
Критериям выбора архивного хранилища она соответствовала идеально. Оптимизированная под запись, легко масштабируемая, совместимая с привычной уже Cassandra, только в разы быстрее… Имя же её — Сцилла (греч. Σκύλλα — «лающая») — напоминая о мифологическом чудовище, рисовало в воображении картины молниеносного поглощения гигантских объемов данных. Сложно было устоять и не попробовать.
Про конечные автоматы (finite state machine, fsm) много кто слышал, но используют их явно в реальных проектах редко. Чаще встречаются конструкции, которые поведением напоминают КА, но ими не являются.
Почему же автоматы обходят стороной и/или изобретают велосипеды, превращая код в спагетти?
По-моему, тут дело в стереотипе: мол, автоматы — это что-то сложное из теоретической математики и к реальной жизни не относится. А применять их можно только в лексических анализаторах или еще чем-нибудь специфичном.
На самом деле, область применения КА куда шире и понятнее. Давайте разберем на примере автоматизации процессов в любимом кровавом enterprise.
Точно скажу, что костыли и велосипеды не лучшее решение, особенно если мы говорим о кэшировании, а конкретнее, если нам надо оптимизировать метод доступа к данным, чтобы он имел производительность выше, чем на источнике. Я докажу это на нескольких примерах, приведённых в статье, всего за 5 минут.
Привет, я Никита, инженер в отделе интеграции в STM Labs.
Вообще STM Labs проектирует и внедряет высоконагруженные системы собственной разработки. Но есть проекты на базе стороннего ПО. Основная задача нашего отдела — заставить чужую систему работать так, как хочет заказчик. Головной офис компании находится в Нижнем Новгороде, а заказчики — по всему миру.
Очень люблю свой нижегородский офис, но самые яркие впечатления от работы я получил не здесь. В прошлом году я пять недель работал в командировке в Африке.
Да, эта статья не про hard skills, а просто про хардкор в Конго.
Весной 2021 года во французском Страсбурге случилось яркое событие: полностью сгорел дата-центр одного из крупнейших европейских хостинг-провайдеров (OVH). Всего за несколько часов пожар отрубил доступ к миллиону популярных сайтов и онлайн-сервисов во всём мире. Одна из вероятных причин — человеческий фактор. В результате под угрозой существования оказался не только сам ЦОД, но и весь бизнес провайдера. К слову, и в России ЦОДы тоже горят. К сожалению, пожар — не единственная проблема больших данных. Не менее опасно — highload системы. Это когда, например, приложение перестаёт справляться с моментальной нагрузкой, а вся инфраструктура работает на пределе возможностей, и запаса для роста у неё нет. Забегая вперед, скажу, что решение есть у каждой из перечисленных проблем. Но, обо всём по порядку.
