Анализ и проектирование систем *

Привет, Хабр!

Log-файлы систематически записывают хронологию событий, происходящих в системе (или приложение). Это может быть что угодно: от записи о запуске программы до детальной информации об ошибках и предупреждениях. Для нас log-файлы — это не просто дневники событий, а очень хороший инструмент для диагностики и устранения проблем.

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

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

В далёкие славные времена мы все работали в офисе и оценка эффективности команды решалась постоянными вербальными контактами. В те времена вовлеченность команды оценивались не столько по цифровым показателям, сколько по времени нахождения всех участников разработки в одном помещении…

В 2020 году мы, как и все, перешли на удаленку. Логично, что через некоторое время у менеджмента возник вопрос — насколько мы там эффективны? И второй, вытекающий из первого: что мы, как менеджмент, делаем для управления этой самой эффективностью?

Для ответов одних бизнес-показателей, очевидно, недостаточно, — они не отвечают на вопрос на сколько эффективно мы растем в ИТ. Нам нужны были метрики производства с учетом методологий и процессов применяемых в организации. В конце концов, мы же хотим понять — эффективна удаленка или нет?

Привет, Habr!

Я Виктор Соловьев – бизнес-аналитик (БА) продукта «Оптимизатор ремонтов» в Первой грузовой компании (ПГК).

Ранее моя коллега Надежда Костякова - техлид продукта, уже начала рассказывать про него в своей статье «Можно ли снизить затраты на ремонт вагонов?». Рекомендую к прочтению.

Сегодня я хочу продолжить тему и подробнее рассказать, что это за зверь такой «Оптимизатор ремонтов». Но как БА считаю неправильно рассказывать про продукт в отрыве от контекста, поэтому начну погружение в проект по пути от общего к частному.

Я работаю в банке, и каждый год мои Product Owners разрабатывают и защищают перед руководством и заказчиками стратегию развития продукта на следующий год. 

Это обязательный ритуал, потому что без этого:

а. Не будет денег на следующий год.
b. Непорядочно в целом называть себя РО и не иметь стратегии развития собственного продукта. 

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

Привет! Меня зовут Даниил Савин. Летом я участвовал в программе стажировки для безопасников от Бастион и в процессе глубоко исследовал тему безопасности приложений, использующих GraphQL. Так появилась статья, из которой вы узнаете:

• какие встроенные функции есть у GraphQL;

• как тестировать GraphQL API;

• какие инструменты использовать;

• и как обходить различные защитные механизмы.

Маленькие вещи могут создавать большие проблемы. И нет, речь не о камешке в ботинке и даже не о вирусах. Мелкие закупки — крупная головная боль для отдела снабжения. А поскольку в ЕВРАЗе активно развивается цифровая трансформация, мы эту головную боль решили лечить не цитрамоном, а соответствующим IT-продуктом. 

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

Все знают, что Россия — энергетическая сверхдержава, она же – «разорванная в клочья Обамой бензоколонка». Но не все знают, как это может отражаться в области развития математического моделирования. Расскажу одну жизненную историю. 

Начну с далекого 2007 года. Довелось мне в те времена поработать на крупном заводе, который «эффективные менеджеры» как раз делили на несколько отдельных предприятий, каждое из которых крутилось, как могло.  В том цеху, который и стал одним из таких предприятий, на токарных станках могла крутиться (и крутилась!) металлическая болванка размером с автобус. А в печку для нагрева металла можно было затолкать паровоз. Целиком.  Когда я в первый раз увидел токарный станок, на котором крутится и обтачивается деталь размером с автобус, моему восторгу не было предела. Гордость за страну переполняла до состояния «в зобу дыханье сперло». А потом старожилы показали ту часть цеха, где стояли фундаменты таких же станков и пояснили:

- А вот тут были станки для точной обработки. Их продали китайцам по цене металлолома.

- А почему вот другие не продали?

- Потому, что у них точность обработки такая, что их только в металлолом можно сдать. Поэтому они здесь работают и крутятся как могут, и обтачивают валы турбин Siemiens.

Схема бизнеса был гениальна: Siemiens привозил на завод многотонные болванки, их неделями и месяцами обтачивали до состояния заготовок и увозили для чистовой обработки в Германию. Где уже выполняли чистовую доводку на точных и дорогих станках. Главные затраты при черновой обработке – это износ станков и инструмента, зарплата токаря и электроэнергия, необходимая для вращения тонн металла. Поскольку электроэнергия в РФ дешевле немецкой, недели обработки болванок с лихвой окупают транспортировку, а низкая точность обработки не требует дорогого обслуживания и мало чувствительна к износу еще советского оборудования.  В итоге весь бизнес заключался в «перепродаже» дешевой электроэнергии из РФ в Германию, но в виде металлических обточенных болванок. 

Маленькая сельская школа, не особо продвинутая технологически. Поскольку школа маленькая, то и учителей в ней немного, и если кто-то не может вести занятия, расписание приходится каждый раз переделывать и вывешивать листочек на стенде — после чего вечером во всех школьных группах начинаются вопросы: а вы расписание сфотографировали? А пришлите!

Меня, конечно, проблема с расписанием не затрагивает вовсе, но как говорится, как-то неаккуратненько. Да и любопытство гложет, а смогу ли я...

Привет, Хабровчане!

Для тех, кто не в курсе, gRPC - это открытый фреймворк от Google, который был представлен миру в 2016 году. Основываясь на протоколе HTTP/2, gRPC использует Protocol Buffers в качестве языка описания интерфейса.

Основная идея gRPC заключается в создании универсального механизма для эффективного и быстрого обмена данными между различными сервисами и приложениями. В этом его главное отличие от традиционных REST API. gRPC работает на основе протоколов, которые определяют "контракты" между клиентом и сервером, позволяя им общаться независимо от ЯПа.

Привет всякому входящему! Сегодня хочу рассказать о том, как сложно спрогнозировать вроде бы простые задачи, на которые по словам «экспертов с интернета» уходит пару дней. Я поделюсь примерами из жизни, когда клиент просит сделать быстренько на коленке, а ты погрязаешь в рутине переделок.

Кому нужны книжки без картинок … или хоть стишков, не понимаю! – думала Алиса

Кому нужны регламенты бизнес-процессов без схемок … или хоть скриптов, не понимаю! –осенило бизнес-аналитика Алису

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

Существует широкий спектр workflow нотаций (стандартов): от классических ГОСТ 19.701-90 (ИСО 5807-85, flowchart), IDEF3, UML2-AD и XML-сериализованных BPMN\YAWL\XPDL\EPML до специфических, например, Дракон.

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

Ниже предложен математический формализм workflow-сетей: Модель WF2M (From workflow to mathematic), WF2M-сеть, как механизм формализации алгоритмов бизнес-процессов в части потока работ (workflow) путем задания аналитическими выражениями функций переходов между дискретными состояниями, маркировки состояний моделируемого объекта. Механизм (механика интерпретации алгоритма бизнес-процесса) заимствует от сетей Петри терминологию (маркировка сети, активация перехода, реализация перехода и т.п.) и частично концептуализм и классификацию. Предложенная WF2M сеть имеет иной механизм формализации (абстракцию) по сравнению с WF-nets.

• В качестве централизованного ресурса, использующего клиент-серверную архитектуру для предоставления возможности редактирования документа всем пользователям.
• На базе одноранговой архитектуры, позволяющей разным людям совместно работать над одним документом.

Пару лет назад в отделе, ответственном за развитие корпоративного хранилища данных «Магнита», работало 5 системных аналитиков: они полностью закрывали весь набор задач, которые перед ними стояли. Но в 2021 году случился резкий рост: данные стали использоваться не несколькими департаментами, как было до, а сразу всей компанией — для масштабных проектов.

Рассказываю, как мы перестроили процессы онбординга для команды, выросшей в 10 раз.

Почему если веб-проект собирается расти, но пока не понимает, куда и как, — виджетная система может стать спасением. Меня зовут Антон Фокин, я CEO студии QTIM и сегодня я расскажу о нашем опыте.

Будучи единственным аналитиком в быстрорастущем сиднейском стартапе, Клэр испытала на себе все тяготы традиционного рабочего процесса аналитика — застревание в "хомячьем колесе", постоянно растущий бэклог и цифры, которые никогда не сходились. Поэтому она освоила dbt, командную строку, контроль версий и привнесла в свою команду всю скрупулезность аналитического инжиниринга. Попутно она так полюбила dbt, что в итоге собрала вещи и переехала в США, чтобы возглавить активно развивающееся сообщество dbt.

Инженеры-аналитики предоставляют конечным пользователям чистые наборы данных, моделируя их таким образом, чтобы конечные пользователи могли сами отвечать на свои вопросы. Сегодня мы с вами поговорим о тенденциях рынка, которые привели к появлению этой новой роли в современных командах по работе с данными.

Привет, Хаброжители! Я Саша, Go-разработчик в компании Сбермаркет. Я со своей командой работаю над созданием инструментов PaaS.

PaaS для нас — это не просто микросервисная архитектура. Это целый мир, в котором с самого начала мы почувствовали потребность в создании эффективного хранилища для всех сервисов, чтобы все было наглядно. Именно так началась наша увлекательная история…

Мы автоматизировали процесс регистрации сервисов при их деплое. Теперь каждый раз, когда новый сервис запускается, он регистрируется в нашей системе. Более того, мы расширили этот процесс, чтобы Huginn собирал важные данные о каждом сервисе, такие как манифест приложения при каждом деплое. Вдруг что-то изменится — мы об этом сразу же узнаем и отображаем!

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

Привет, Хабр!

Сегодня мы поговорим о временных рядах, и как мы можем работать с ними, используя ЯП R. Временные ряды позволяют понять динамику процессов, изменяющихся со временем, и предсказывать тенденции.

Понимание Извлечения (Extract), Загрузки (Load) и Трансформации (Transform) независимо друг от друга

В свете быстрого развития информационных систем и увеличения угроз кибербезопасности поиск надежных решений, позволяющих минимизировать вред от нарушения информационной безопасности (ИБ), становится важной задачей для различных организаций. Когда инфраструктура организации начинает настолько усложняться, что становится невозможно уследить за общей картиной происходящего, на помощь приходит Центр обеспечения безопасности (SOC, Security Operations Center) — это широко специализированный ситуационный центр мониторинга информационной безопасности, совокупность программно‑аппаратных средств, персонала и процессов. Данный тип систем предназначен для централизованного сбора и анализа информации о событиях и инцидентах ИБ, поступающих из различных источников ИТ‑инфраструктуры.

Существует множество конкретных решений, но без ряда базовых средств мониторинга и защиты информации сложно себе представить даже внутренний SOC в средней компании, не говоря уже о коммерческом центре. К таким средствам принято относить системы различного класса, где каждый элемент выполняет свою функциональную роль, и одними из центральных и наиболее эффективных являются платформы IRP — отдельные системы для выстраивания процессов управления инцидентами, которые предназначены для автоматизации процессов мониторинга, учета и реагирования на инциденты, а также для решения типовых проблем управления ИБ.

Применение IRP позволяет обеспечивать своевременные ответные действия группы реагирования на инциденты информационной безопасности, предоставляя при этом аналитическую информацию и контекст отслеживаемого события. В данной статье мы как раз рассмотрим одну из таких платформ — The Hive, которая предоставляет комплексное решение для эффективного управления и реагирования на инциденты безопасности.