User
Анна Вичугова, CBAP, написала стартовое пособие по тому, как начать моделировать бизнес-процессы в BPMN
1. Назначение BPMN.
2. Уровни моделирования.
3. Алфавит нотации: События, Логические операторы, Артефакты.
4. Правила построения диаграмм.
5. Пример построения диаграммы по тексту.
6. Рекомендуемые инструменты.
На прошедшей неделе вышло сразу несколько новых Open Source LLM. Разбираемся, что в них особенного, а также как и зачем их запускать локально.
Привет, Хабр! В этой и последующих публикациях мы, Михаил Левицкий и Алексей Федоров, расскажем про ленты как устройства и носители для хранения данных, поговорим о том, какие они бывают, как используются и как происходит резервное копирование и восстановление с лент в нашем продукте Кибер Бэкап. Надеемся, что вам будет также интересно читать, как нам, когда мы готовили этот материал. Итак, поехали.
Хабр, привет!
В начале своего пути я далеко не сразу смог понять, кто же такие эти ваши требования, как их писать и как они должны выглядеть? Предлагаю взглянуть на мое видение идеальной доки, покрывающие все аспекты проекта. Данный шаблон охватывает все аспекты проекта: бизнес-анализ, системный анализ и продуктовую аналитику.
Идеальная документация должна выполнять две основные функции...
В статье рассказываем о том, кому стоит задуматься о внедрении DWH, как сократить вероятность ошибок на этапе разработки проекта, выбрать стек, методологию и сэкономить ИТ-бюджеты.
Привет, Хабр! Мне, наконец, есть чем поделиться с вами. И это результаты практически годового процесса выбора BI-системы из числа российских разработок на замену одной из западных платформ. За это время мне стало очевидно, что примерно 50% действий, которые мы сделали, можно было и не делать, а 20% не стоило делать вовсе. В итоге получилась практически инструкция “как не надо” выбирать себе BI-систему, если вы хотите, чтобы она действительно начала приносить вам пользу ASAP. Под катом — также мои мысли о том, как надо было бы. Желающих обсудить, прошу присоединяться.
1С работает с СУБД Postgres более 10 лет, а сейчас это единственный легальный вариант для инсталляций в России. Много ли мы потеряем в производительности по сравнению с MS SQL ? Выдержит ли Postgres 15.2 жесткий Highload со стороны 1С? Цель этой статьи - ответить на данные вопросы, с цифрами, которые можно использовать при расчете архитектуры.
В финальной статье мне хочется поделиться кейсом повышения безопасности одного из самых важных компонентов инфраструктуры — базы данных (в моём случае — PostgreSQL v14 с управлением через patroni). Расскажу про то, как повысить скорость анализа потенциальных инцидентов, как настроить процессы шифрования дисков, как сгенерировать SSL‑сертификаты для базы данных и обеспечить их двухстороннюю проверку. А ещё поговорим про бэкапы и wal‑g-backup. Надеюсь, статья поможет каждому избежать ошибок в планировании и узнать что-то новое.
Снова приветствую дорогих читателей! Продолжаю цикл статей "ШХ" и сегодня нашим блюдом будет Telegram. В предыдущих статьях мы рассмотрели способы анализа аккаунтов целевого пользователя по его никнейму, после чего проводили разведку его аккаунта в социальной сети Вконтакте. Сейчас я ставлю для себя важным узнать номер телефона пользователя, так как от номера уже можно будет неплохо отталкиваться в разведке и номер телефона может поведать еще больше о своём владельце. В прошлой статье мы пытались выяснить номер при помощи страницы Вконтакте, а в этой как уже догадались по названию, мы будем пытаться выяснить как можно больше информации о Telegram аккаунте.
Дисклеймер: Все данные предоставленные в данной статье, взяты из открытых источников. Не призывают к действию и являются только лишь данными для ознакомления, и изучения механизмов используемых технологий.
Участие в ВТО потребовало стандартизации терминов и определений, для: «предупреждения действий, вводящих в заблуждение приобретателей, в том числе потребителей» (ст. 6, 46 184-ФЗ). Общепринятая двухуровневая система разделения на обязательные техрегламенты и добровольные ГОСТы становится одноуровневой после требований ст.46 184-ФЗ, при создании описаний и в контрактах на поставку и, соответственно, для используемых терминов и интерпретации их определений. В данном словаре представлены десятки тысяч определений, чтобы эффективнее реализовывать различные задачи в IT отрасли.
Жизненный цикл любого проекта включает в себя этапы инициации, планирования, исполнения, контроля и завершения. Гибкие методологии и итерационный подход используют в проектах по разработке программного обеспечения всё чаще. С ними этапы проекта повторяются несколько раз для каждой итерации, а перечень инструментов аналитика максимально упрощается и сводится до написания user story.
Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта. Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик».
Начинающим аналитикам бывает не просто разобраться в разных подходах к документированию требований и множестве нотаций моделирования. У кого-то даже проскальзывают сомнения, а нужно ли все это знать или можно просто изучить формат описания user story? Я попробую развеять эти сомнения на примере учебного проекта.
Сегодня поговорим об управлении рисками в IT-разработке. Материал будет интересен в первую очередь продактам, менеджерам проектов, бизнес-аналитикам, тим-лидам и всем, кто в той или иной мере желает снизить влияние непредвиденных негативных факторов на проект или продукт.
В современном IT мы часто работаем в зоне максимальной волатильности, неопределенности, постоянных изменений, сложных коммуникаций, конструктивных и деструктивных конфликтов, ограничений.. И большая часть из нас очень не любит работать в стол. Нам хочется видеть результат своих трудов. Бывает обидно, когда какие-то непредвиденные обстоятельства (т.е. риски) – перечеркивают все наши планы..
О том, как управлять влиянием этих рисков- мы и поговорим сегодня.
На самом деле, не открою какой-то космос – техника очень хорошо описана в BABOK (10.38 - Risk Analysis and Management). Но на практике вижу, что не только менеджеры, но даже аналитики (для которых это стандарт - как учебник) не используют технику. Многие ошибочно считают управление рисками чем-то скучным, рутинным, бесполезным, формальным. Хотя на деле это очень эффективный и вовсе не сложный инструмент.
Задача этой статьи - кратко и понятно показать, как можно внедрить в практику управление рисками. Постараюсь описать все так, чтоб уже завтра вы могли внедрить ее на своем проекте без изучения дополнительных источников. Если вам удобнее воспринимать в видео-формате, то можно посмотреть мой интерактивный доклад на эту тему на YouTube:
Для бизнеса и интеграции с CRM есть два варианта подключения WhatsApp — неофициальный «серый» и официальный WhatsApp Business API. «Серый» имитирует действия обычного пользователя приложения WhatsApp Web. Это может привести к блокировке номера от Facebook* из-за нарушения правил предоставления услуг.
По нашей статистике большая часть компаний все еще выбирают для общения с клиентом «серый» WhatsApp. Да, это нарушение правил компании Facebook*, но такова реальность.
Почему именно WhatsApp, а не другие каналы? WhatsApp все еще самый популярный мессенджер в России — по данным Mediascope на январь 2024 в сутки им пользуется 67% населения. А «серое» подключение — самый бюджетный вариант использования мессенджера для бизнеса, который позволяет писать первым и создавать рассылки.
Но использование «серого» WhatsApp сопровождается рисками — компания Facebook* регулярно блокирует «серые» аккаунты. И алгоритмы, по которым их вычисляют, постоянно совершенствуются.
В статье мы подробнее расскажем о проблемах использования «Серого» WhatsApp, как их решают пользователи и о том, как повысить эффективность общения за счет альтернативных каналов.
Серый WhatsApp
Источник проблем при использовании — подключение в нарушение пользовательского соглашения WhatsApp. Следствие — постоянный риск блокировки.
Распространённые причины блокировок:
Управлять ИТ‑ инфраструктурой — сложно. Всегда есть фактор, который опасно не учесть. Не сделали резервные копии, администратор выполнил не ту команду (намеренно или случайно) — и масштабы аварии вырастают из небольшого огонька в пожар.
Для наглядности сравним ИТ‑инфраструктуру с историей из фильма «Парк Юрского Периода». Началось с вдохновляющей идеи — построить тематический парк с динозаврами, которых оживляют с помощью клонирования. Однако сбой в системе безопасности привел к хаосу и борьбе за выживание среди посетителей и динозавров. Возможно ли было предотвратить сбой и не подвергать жизни людей опасности? Безусловно, но по разным причинам (от беспечности руководства до жадности персонажа) катастрофа все‑таки случилась. В повседневной жизни риски аварий растут каждый день из‑за разных факторов. В таких условиях обеспечить бесперебойную работу ИТ‑инфраструктуры так же сложно и рискованно, как и управлять парком с динозаврами.
Всем привет, снова на связи СЕО CRM-интегратора Пуск, Сергей Михнов. Хочу поделиться опытом команды о доработках коробочного Битрикс24.
Сразу скажу, это не реклама коробочной версии или Битрикс24 в принципе, но из песни слов не выкинешь. Еще в начале пути мы постепенно пришли к тому, что лучше специализироваться на одном продукте и делать это глубоко и качественно, чем оказывать большой пул услуг, рассеивая внимание на разноплановые задачи. Поэтому от системного администрирования корпоративных сетей и сопровождения любых корпоративных порталов мы ушли в сторону коробки всем известной crm-системы. Сам вендор, кстати говоря, активно пиарит облако :)
Мы же видим больше преимуществ в коробочной версии хотя бы потому, что это: а) возможность хранить данные на собственных серверах; б) доступ к коду и возможность переделывать систему под логику бизнеса.
Из собственной практики могу сказать, что это довольно стандартная история, когда компания упирается в тупик возможностей своей CRM. Готовых инструментов не хватает, нужно искать что-либо на стороне или пробовать кастомизировать то, что есть. Поэтому мы и работаем преимущественно с коробочной версией Битрикс24, ведь она поддается оптимизации. Можно внедрять собственные разработки или переделывать существующие инструменты. Но, как и в любом другом деле, здесь есть свои риски.
Пришел ко мне хороший приятель с просьбой помочь разобраться с защитой персональных данных, так как недавно к нему заглянули ответственные товарищи и напугали огромной ответственностью – типа штрафы выросли за прошлый год в 6000 раз. Я в этой теме поковырялся и обнаружил, что многие валят в одну кучу и требования к защите персональных данных в соответствии со 152 ФЗ и уровнями защищенности от 1-го до 4-го, и требования по 242 ФЗ в части локализации обработки персональных данных граждан РФ. Дисклеймер:
В 90% случаев нужен 3-й уровень. Вот его повально все нарушают, даже не подозревая об этом!
При размещении 1С в облачной инфраструктуре и среде виртуализации наиболее важными и непростыми задачами являются повышение скорости работы платформы «1С» и настройка СУБД. Для достижения максимальной производительности инфраструктуры 1С рекомендуется правильно выбирать архитектуру инфраструктуры, режимы работы, проверить и выполнить ряд важных настроек: