За пару дней до выхода статьи эта же аналитик подговорила наших ребят участвовать в командном хакатоне. Результат не самый приятный — 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 системы. Это когда, например, приложение перестаёт справляться с моментальной нагрузкой, а вся инфраструктура работает на пределе возможностей, и запаса для роста у неё нет. Забегая вперед, скажу, что решение есть у каждой из перечисленных проблем. Но, обо всём по порядку.
Меня зовут Ирина Козлова, я — старший бизнес-аналитик в ИТ-компании STM Labs. Помимо моих ключевых обязанностей: бизнес и системный анализ, сбор и управление требованиями, я принимаю непосредственное участие в приемке макетов от дизайнеров.
Разрабатывая продукт с нуля, можно столкнуться с множеством проблем и трудностей. Одна из них – как нарисовать хороший дизайн. В своей статье расскажу, как бизнес-аналитик может помочь при проектировании дизайна интерфейса и может ли у дизайна быть KPI. Материал позволит вам узнать несколько ключевых аспектов для создания дизайна продукта, которым удобно, а главное хочется пользоваться.
«Традиционно, самым узким местом в архитектуре любой информационной системы является система управления базами данных (СУБД). Можно сколько угодно оптимизировать прикладное программное обеспечение (ПО), но все равно упремся в ограничения в части производительности запросов». В своем материале я рассказываю о том, как построить архитектуру системы без слабых мест, и кого для этого стоит принести в жертву.
Языков в мире программирования масса, но корону по праву носит Python. Многие полюбили его за гибкость, лаконичность, бесчисленное количество модулей и поддержку сообщества. Именно этот язык стал основой для самых популярных мировых площадок: YouTube, Instagram, Uber и многих других. Однако, некоторые программисты считают Python языком с ограниченными возможностями и уверены, что он «задохнется» под тяжелой архитектурой highload системы.
Я, технический директор компании STM Labs, Андрей Комягин, за несколько минут смогу переубедить всех скептиков и доказать обратное.