Vba

Pedro Tavares

Обнаруженное недавно семейство вредоносного ПО под названием Epic Manchego использует хитрый трюк для создания вредоносных файлов MS Excel с минимальной степенью обнаружения и повышенной вероятностью обхода систем безопасности. Изучая способы обхода систем безопасности, используемые злоумышленниками, можно понять, какие первоочередные меры следует предпринять для защиты систем от атак подобного рода.

Описание угрозы

Семейство вредоносного ПО "работает" с июня 2020 года и атакует организации из разных стран с применением фишинговых сообщений электронной почты, содержащих изменённый файл Excel. Чтобы фишинговые сообщения не попадали в папки со спамом и против них не срабатывали механизмы отсечения нежелательной почты, злоумышленники отправляют свои письма с официальных учётных записей организаций. Учётные данные таких организаций, как правило, попадают в руки злоумышленников в результате взлома. Злоумышленники с помощью сервиса проверки аккаунтов на утечки "Have I Been Pwned?" проверяют, были ли скомпрометированы учётные записи электронной почты, или просто взламывают такие записи до того, как приступить к вредоносной рассылке.

Согласно данным NVISO, "через VirusTotal было пропущено около 200 вредоносных документов, и был составлен список из 27 стран, ранжированных по количеству отправленных документов. В списке не делалось различие, каким способом загружались такие файлы (возможно, через VPN)".

В ходе исследования выяснилось, что наибольшему риску рассылки вредоносных файлов подвергаются такие страны, как Соединённые Штаты Америки, Чешская Республика, Франция, Германия и Китай.

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

Как работает Epic Manchego

В некоторых рассылаемых документах Office содержатся нарисованные фигуры, например прямоугольники, как это показано на рисунке 4.

Вредоносные документы Microsoft Office создаются не через Microsoft Office Excel, а с использованием .NET библиотеки EPPlus. Поскольку такие документы не являются стандартными документами Excel, они могут маскироваться и обходить защитные механизмы.

Документ на рисунке 4 содержит объект drawing1.xml (скруглённый прямоугольник) с именем name="VBASampleRect и создан с использованием исходного кода EPPLUS Wiki (справа), как это показано ниже.

Если открыть окно макросов документа, в нём не будет ни одного макроса.

Тем не менее вредоносный код существует и к тому же защищён паролем. Интересно отметить, что этот код VBA вообще не зашифрован, а представлен открытым текстом.

При открытии документа с VBA-проектом, защищённым паролем, макросы VBA будут запускаться без пароля. Пароль необходим только для просмотра проекта VBA внутри интегрированной среды разработки (IDE) VBA.

Если внести изменения в строку DPB или дешифровать пароль, можно увидеть, что при запуске вредоносного файла Office на компьютере жертвы запускается и выполняется полезная нагрузка PowerShell.

На приведённом ниже скриншоте продемонстрирован запуск полезной нагрузки PowerShell во время заражения.

Согласно результатам исследования NVISO Labs, чтобы загрузить полезную нагрузку в коде VBA, используются либо объекты PowerShell, либо объекты ActiveX, в зависимости от разновидности исходного вредоносного ПО.

Анализ завершающего этапа работы вредоносного ПО

Через вредоносный код VBA на втором этапе с различных интернет-сайтов загружается полезная нагрузка. Каждый исполняемый файл, создаваемый соответствующим вредоносным документом и запускаемый на втором этапе, выступает для конечной полезной нагрузки как носитель вируса (дроппер). После этого на втором этапе также загружается вредоносный файл DLL. Этот компонент DLL формирует дополнительные параметры и полезную нагрузку для третьего этапа, после чего запускает на выполнение конечную полезную нагрузку, которая, как правило, крадёт информацию.

Как отмечают исследователи из NVISO Labs, "несмотря на то что описанная выше схема обфускации данных применяется многими вредоносными программами, мы видим, как она усложняется, поэтому существует вероятность применения более изощрённых методик".

Кроме того, "общим фактором второго этапа заражения является использование методов стеганографии (то есть тайной передачи информации путём сокрытия самого факта передачи) с целью маскирования злонамеренного умысла".

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

Чаще всего (более чем в 50% случаев) на компьютер жертвы устанавливается вредоносная программа AZORult, похищающая личные данные пользователей, программы для кражи информации называются инфостилерами. В качестве других полезных нагрузок могут использоваться трояны AgentTesla, Formbook, Matiex и njRat, причем Azorult и njRAT имеют высокий уровень повторного использования.

Обнаружение и действия

Для запуска вредоносных программ злоумышленники придумывают новые методы обхода систем обнаружения угроз и реакции на конечных точках (EDR) и антивирусных программ (AV). При использовании нового способа создания вредоносных документов Office механизмы обнаружения угроз не должны позволять вредоносному ПО переходить на следующий этап. Часто на этом этапе запускается скрипт PowerShell, который может выполняться в памяти без обращения к диску.

Обнаружение и блокирование новых способов заражения посредством создания вредоносных документов (maldoc), один из которых описывается в настоящей статье, позволит организациям оперативно реагировать на инциденты. Для предотвращения атак подобного рода рекомендуется принимать следующие меры:

• Предупредить пользователей, что они могут стать объектами социальной инженерии, и научить их правильно вести себя в случаях атак.

• Регулярно обновлять программное обеспечение, приложения и системы до последних версий.

• Использовать решения защиты конечных точек (Endpoint Protection) и обновлённое антивирусное ПО для предотвращения заражения вредоносными программами.

• Использовать системы управления уязвимостями и мониторинга для выявления потенциальных неустранённых уязвимостей и инцидентов в режиме реального времени.

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Источники:

• Epic Manchego, NVISO Labs.

• Использование библиотеки .NET для обхода антивируса, ZDNet.

Предыстория

Как известно Лень двигатель прогресса. В своей работе однажды я столкнулся задачей, когда нужно было составить таблицу расчёта процентов по договору займа, где за базу должно было быть фактическое количество дней в году. Неудобство составляло то, что нужно было не забыть про високосные года и разделять дни, которые относятся к високосному году и дни не високосных лет. Была написана простенькая формула, но позже я выяснил, что расчётом високосных лет не всё так просто.

Описание проблемы

Мне захотелось улучшить формулу. В интернете я нашёл много текстов программ, где вычислялось количество високосных или невисокосных лет и дней в периоде. Но, к сожалению, мен не устраивал тот факт, что скорость работы данных функций зависела от количества лет в периоде. А хотелось, чтобы независимо от того, сколько лет в периоде, функция работала также быстро. Но в ходе разработки мне пришлось ограничить допустимый период работы функции.

Причина 1

Большинство стран живут по Григорианскому календарю, правила високосных лет для которого были определены ещё 1582 году римским папой Григорием XIII:

1. Год, номер которого кратен 400, - високосный;

2. Остальные годы, номер которых кратен 100, - невисокосные (например, годы 1700, 1800, 1900, 2100, 2200,2300)

3. Остальные годы, номер которых кратен 4, - високосные.

Также существует неоднозначность в мнениях определения високосных лет таких как 2900, 3200, 4000, поэтому я решил ограничить функцию максимальной датой 01.01.2900.

Причина 2

Пользовательская функция в Excel создаётся на языке VBA (Visual Basic for Applications). Несмотря на то, что интерпретатор данного языка встроен в MS Office, я обнаружил некоторые отличия в работе с датами.

Excel поддерживает две системы дат, так называемые системы 1900 и 1904. По умолчанию используется система 1900. Это означает, что число 1 введённое в ячейку соответствует 01 января 1900 года, 2 2 января и так далее.

В VBA есть функция CDate(expression), которая приводит к типу Date введённое значение. И если этой функции передать число 1, то она вернёт переменную типа Date с датой 31 декабря 1899 года. А вот для числа 60 функция CDate вернёт 28.02.1900, а то же значение введённое в ячейку будет отображать 29.02.1900 (хотя, конечно, 1900 год високосным не является). Далее, начиная с 01 марта 1900 года значения дат выравниваются.

Такое поведение Excel, давно известно компании Microsoft и было принято решение оставить как есть, нужно просто учитывать его. Поэтому и появилось второе ограничение минимальной даты периода 01 марта 1900 года.

Алгоритм решения

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

Так как все делители, с помощью которых мы можем определить високосность года кратны 4, то я решил разбить все годы на блоки по 4 (квартеты) начиная с 1 года. То есть 1-й блок начинается с 1 года и заканчивается 4, 2-й блок с 5 по 8 и так далее.

В каждом блоке год будет иметь свой индекс от 1 до 4 (например, 2021 год это 506-й блок, индекс в блоке 1)

Теперь мы можем разделить вычисление на 3 блока:

В зависимости от года параметров и индексов квартетов формула расчёта количества дней високосного года будет следующей:

Если год начальной и конечной даты равны и год високосный:

Если год начальной даты невисокосный, а конечной високосный и индексы квартета начальной даты и конечной равны, то:

Если год начальной даты високосный, а конечной нет, то:

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

Выше указанная логика расчёта количества дней високосных лет для первого квартета реализована следующей функцией на VBA:

Private Function first_quartet_leap_year_days(ByVal d_begin As Date, ByVal d_end As Date) As Long    Dim result As Long    result = 0        Dim year_diff As Long    Dim quartet_index_diff As Long        year_diff = year(d_end) - year(d_begin)    quartet_index_diff = quartet_index(year(d_end)) - quartet_index(year(d_begin))        If year_diff = 0 And is_year_leap(d_begin) Then        result = DateDiff("d", d_begin, d_end)        first_quartet_leap_year_days = result        Exit Function    End If        If quartet_index_diff = 0 Then            If is_year_leap(d_begin) Then            result = DateDiff("d", d_begin, CDate(DateSerial(year(d_begin), 12, 31)))            first_quartet_leap_year_days = result            Exit Function                End If                If is_year_leap(d_end) Then            result = DateDiff("d", CDate(DateSerial(year(d_end) - 1, 12, 31)), d_end)            first_quartet_leap_year_days = result            Exit Function        End If            Else            If is_year_leap(d_begin) Then            result = DateDiff("d", d_begin, CDate(DateSerial(year(d_begin), 12, 31)))            first_quartet_leap_year_days = result            Exit Function        Else                    If Not is_quartet_noleap(quartet_index(year(d_begin))) Then                result = 366                first_quartet_leap_year_days = result                Exit Function            End If                    End If            End If    first_quartet_leap_year_days = result    End Function

Если разница индексов квартетов начальной и конечной даты >0, то рассчитывается 3-й блок формулы "Количество високосных дней в последнем квартете".

Здесь формула только одна, где при условии, что год конечной даты високосный:

Private Function last_quartet_leap_year_days(ByVal d_begin As Date, ByVal d_end As Date) As Long        Dim result As Long    result = 0         Dim quartet_index_diff As Long           quartet_index_diff = quartet_index(year(d_end)) - quartet_index(year(d_begin))        If quartet_index_diff > 0 Then            If is_year_leap(d_end) Then            result = DateDiff("d", CDate(DateSerial(year(d_end) - 1, 12, 31)), d_end)        End If            End If             last_quartet_leap_year_days = result    End Function

Если разница индексов квартетов начальной и конечной даты >1, то рассчитывается 2-й блок формулы "Количество високосных дней в промежуточных квартетах".

При этом К полных столетий означает разность индексов столетий между датами. Например 1999 индекс столетия 19, а 2001 20, таким образом разность столетий 1.

Аналогично и 400-летий.

Private Function middle_quartets_leap_year_days(ByVal d_begin As Date, ByVal d_end As Date) As Long        Dim quartet_count As Long        quartet_count = middle_quartets_count(d_begin, d_end)        If quartet_count = 0 Then            middle_quartets_leap_year_days = 0        Exit Function            End If        Dim q_begin, q_end As Long        q_begin = quartet_index(year(d_begin))    q_end = quartet_index(year(d_end)) - 1        Dim quot_25, quot_100 As Integer        quot_25 = WorksheetFunction.Quotient(q_end, 25) - WorksheetFunction.Quotient(q_begin, 25)    quot_100 = WorksheetFunction.Quotient(q_end, 100) - WorksheetFunction.Quotient(q_begin, 100)        Dim result As Long        result = (quartet_count - quot_25 + quot_100) * 366        middle_quartets_leap_year_days = result        End Function

Реализация функций

Функция вычисления високосных дней для периода:

Public Function LEAP_DAYS(ByVal val_begin As Long, ByVal val_end As Long, Optional count_first_day = 0, Optional count_last_day = 1) As Long        Dim d_begin, d_end As Date        count_first_day = IIf(count_first_day <> 0, 1, 0)    count_last_day = IIf(count_last_day <> 0, 1, 0)            d_begin = CDate(val_begin)    d_end = CDate(val_end)        Dim check_error As Variant    check_error = check_constrains(d_begin, d_end)        If IsError(check_error) Then        LEAP_DAYS = check_error        Exit Function    End If        Dim result As Long    result = 0        If is_year_leap(d_begin) And count_first_day = 1 Then result = result + 1    If is_year_leap(d_end) And count_last_day = 0 Then result = result - 1        result = result + first_quartet_leap_year_days(d_begin, d_end) _            + middle_quartets_leap_year_days(d_begin, d_end) _            + last_quartet_leap_year_days(d_begin, d_end)        LEAP_DAYS = result    End Function

В приведённом выше коде мы сначала приводим значения параметров count_first_day и count_last_day к значению 1 или 0. Затем мы объявляем переменные типа Date для даты начала и окончания периода и задаём значения. Далее следует проверка параметров на ограничения.

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

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

Заключение

Таким образом мы получили формулы расчёта количества дней високосных и невисокосных лет в заданном периоде, скорость которой не зависит от количества дней в периоде. Единственный минус это то, что формула способна корректно работать только в рамках одной тысячи лет (2900 - 1900). Думаю, что до 2900 года у нас есть ещё время усовершенствовать такую функцию.

Ниже ссылка на гитхаб, где выложена полная реализация функций подсчёта високосных и невисокосных дней в периоде на VBA предназначенная для работы в Excel. Вы легко сможете портировать эту функцию на Ваш любимый язык и пользоваться в своих проектах.

Гитхаб

Источники и дополнительные ссылки

1. Статья из журнала "Главная книга" "Считаем проценты по займу: день первый, день последний"

2. Excel неправильно предполагает, что 1900 год является високосным годом.

3. Статья из Википедии "Григорианский календарь"

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

Но в современном мире иметь API недостаточно мало кто хочет формировать HTTP-запросы, передавать параметры, думать про правильную авторизацию. Поэтому мы предлагаем SDK для разных языков программирования: Python, PHP, C# и многих других. И кажется, что этого достаточно, чтобы сделать нашу платформу лёгкой в использовании для очень большой аудитории. Или всё-таки недостаточно?

Обратимся к статистике. По разным данным сейчас в мире насчитывается где-то 15-30 миллионов разработчиков цифра несомненно впечатляющая. Но, например, пользователей MS Excel в мире не менее 100 миллионов. Почему же они должны страдать? Ведь, будем честны, почти каждый из тех, кто хоть раз открывал Excel, явно ощущал недостаток возможностей по управлению коммуникационными платформами в этом без сомнения очень гибком программном продукте. Практически каждый день мы получаем на наш email сотни запросов, которые сводятся к очень простой просьбе: Я хочу звонить из Excel!. Однажды у окон нашего офиса даже выстроились люди с такими требованиями (видели фото выше?) Мы просто не могли оставаться в стороне.

Однако звонки это всё-таки слишком революционно, а главное, потребует установки дополнительных ActiveX-компонентов, что, безусловно, противоречит всем существующим и несуществующим политикам информационной безопасности, поэтому давайте начнём с более простой вещи SDK для работы с нашим API. Из средств разработки в Экселе доступен VBA, для него мы и создадим SDK.

Для того, чтобы выполнить API-запрос, необходимо:

1. Сформировать URL и тело POST-запроса.

2. Добавить аутентификационные параметры.

3. Непосредственно выполнить запрос.

4. Распарсить результат (в нашем случае это JSON).

Формируем URL и тело POST-запроса

Первая часть, казалось бы, самая простая: нужно просто закодировать параметры в URL-кодировку и склеить их. Но в стандартом VBA не предусмотрена URL-кодировка (позже мы поймём, почему). Ничего страшного, на просторах Интернета есть множество разных решений, выберем одно из них.

Public Function URL_Encode(ByRef txt As String) As String    Dim buffer As String, i As Long, c As Long, n As Long    buffer = String$(Len(txt) * 12, "%")     For i = 1 To Len(txt)        c = AscW(Mid$(txt, i, 1)) And 65535         Select Case c            Case 48 To 57, 65 To 90, 97 To 122, 45, 46, 95  ' Unescaped 0-9A-Za-z-._ '                n = n + 1                Mid$(buffer, n) = ChrW(c)            Case Is <= 127            ' Escaped UTF-8 1 bytes U+0000 to U+007F '                n = n + 3                Mid$(buffer, n - 1) = Right$(Hex$(256 + c), 2)            Case Is <= 2047           ' Escaped UTF-8 2 bytes U+0080 to U+07FF '                n = n + 6                Mid$(buffer, n - 4) = Hex$(192 + (c \ 64))                Mid$(buffer, n - 1) = Hex$(128 + (c Mod 64))            Case 55296 To 57343       ' Escaped UTF-8 4 bytes U+010000 to U+10FFFF '                i = i + 1                c = 65536 + (c Mod 1024) * 1024 + (AscW(Mid$(txt, i, 1)) And 1023)                n = n + 12                Mid$(buffer, n - 10) = Hex$(240 + (c \ 262144))                Mid$(buffer, n - 7) = Hex$(128 + ((c \ 4096) Mod 64))                Mid$(buffer, n - 4) = Hex$(128 + ((c \ 64) Mod 64))                Mid$(buffer, n - 1) = Hex$(128 + (c Mod 64))            Case Else                 ' Escaped UTF-8 3 bytes U+0800 to U+FFFF '                n = n + 9                Mid$(buffer, n - 7) = Hex$(224 + (c \ 4096))                Mid$(buffer, n - 4) = Hex$(128 + ((c \ 64) Mod 64))                Mid$(buffer, n - 1) = Hex$(128 + (c Mod 64))        End Select    Next    URL_Encode = Left$(buffer, n)End Function

Следующий нюанс передача даты и времени. В API Voximplant временные метки принимаются в UTC в формате YYYY-MM-DD hh:mm:ss. В Excel же дата и время хранятся без учёта часового пояса (на самом деле, в самой таблице они вообще хранятся как число с плавающей точкой). Поэтому нам придётся принимать дату/время из таблицы тоже UTC. Мы думаем, что все 100+ миллионов пользователей Excel знают, что такое UTC, и это не вызовет у них никаких вопросов.

Кстати, в VBA есть функция форматирования даты, и она даже работает, но весьма необычным образом. Интересующий нас формат даты описывается так: yyyy-mm-dd hh:mm:ss. То есть mm это либо месяц, либо минуты в зависимости от того, за чем оно следует: за hhили за yyyy (это не шутка, это даже в MSDN описано). В общем, если кто-то захочет вывести время без часов, придётся импровизировать.

Переходим к аутентификации

Здесь нас ожидает самое большое разочарование. Мы в Voximplant предлагаем нашим клиентам использовать JWT, что, конечно, весьма мудрёно, если выполнять запросы из консоли или браузера, но при использовании наших SDK это совершенно никак не усложняет жизнь разработчику. В то же время JWT обеспечивает крайне высокий уровень безопасности.

А что же VBA? К сожалению, разумно простого способа сформировать JWT-подпись просто не существует. Причина в том, что в VBA доступен фреймворк .NET версии 4.x, а функция RSA.ImportPkcs8PrivateKey, необходимая для загрузки приватного ключа из PKCS8, появилась только в .NET 5. Да и вообще, все .NET-разработчики используют для таких задач сторонние библиотеки.

Поэтому нам придётся ограничиться авторизацией с помощью статического API-ключа. Ведь, как известно, один из способов обработки риска информационной безопасности - принятие этого риска. Так и поступим. Ведь нам ну очень-очень нужен этот SDK.

Выполняем запрос

Переходим к третьей части к выполнению самого запроса. Встроенных средств работы с HTTP в VBA нет (теперь понятно, почему нет и функции URL-кодирования, а зачем?).

Но, тем не менее, это достаточно тривиальная манипуляция подключаем необходимый фреймворк MSXML 6.0 и Microsoft Scripting Runtime и выполняем запрос, подключая через COM сам MSXML. Просто!

Function makeRequest(name As String, params As Dictionary, accountId As Integer, apiKey As String) As Object    Dim objHTTP As New MSXML2.XMLHTTP60    Dim jsonData As String    Dim parsedJson As Object    Dim postString As String    postString = ""        Dim iterKey As Variant        For Each iterKey In params.Keys        postString = postString & "&" & iterKey & "=" & URL_Encode(params(iterKey))    Next    Url = "https://api.voximplant.com/platform_api/" + name    objHTTP.Open "POST", Url, False    objHTTP.send "account_id=" & accountId & "&api_key=" & apiKey & postString    jsonData = objHTTP.responseText    Set parsedJson = JsonConverter.ParseJson(jsonData)    Set makeRequest = parsedJsonEnd Function

Парсим JSON

Ну и, наконец, JSON. Как и всё остальное, парсер JSON надо искать где-то вовне экосистемы VBA. К счастью, на дворе 2021 год, есть GitHub, и кто-то уже озадачился созданием JSON-парсера для VBA. Мы взяли вот такой.

Он подключается как отдельный модуль и превращает JSON-строку в Dictionary. То, что нужно!

Дальше берём генератор одного из наших SDK (мы взяли питоновский), заменяем шаблоны и заставляем его генерировать код на VBA. В итоге получаем готовый SDK, который можно скачать на нашем GitHub.

SDK представляет собой Class Module, который можно подключить к вашей любимой книге в Excel и делать с его помощью разные странные вещи. В принципе, можно даже звонки запускать, SDK поддерживает все необходимые для этого функции API в). Но это будет не лучшей идеей, учитывая, что не до конца известно, когда Excel решит пересчитать все формулы (именно в этот момент произойдёт вызов функции API).

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

Для этого пишем вот такую функцию:

Function getTotalCallCost(FromDate, ToDate, Username) As Double    Dim totalCost As Double    Dim lastCount As Integer    Dim offset As Integer    Dim res As Dictionary    Dim RecordsPerRequest As Integer    Dim api As New VoximplantAPI    totalCost = 0    lastCount = 1    offset = 0    RecordsPerRequest = 100        'Pass Voximplant account id and API key    api.SetCredentials 100, "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"        Do While lastCount > 0        Set res = api.GetCallHistory(FromDate, ToDate, remote_number:=Username, with_calls:=True, with_records:=True, with_other_resources:=True, offset:=offset, count:=RecordsPerRequest)                Dim session As Variant        Dim item As Variant                For Each session In res("result")            For Each item In session("calls")                totalCost = totalCost + item("cost")            Next            For Each item In session("records")                totalCost = totalCost + item("cost")            Next            For Each item In session("other_resource_usage")                totalCost = totalCost + item("cost")            Next        Next                lastCount = res("count")        offset = offset + RecordsPerRequest    Loop        getTotalCallCost = totalCostEnd Function

И вызываем её следующим образом:

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

Резюме:

При желании можно и для VBA сделать какое-то подобие SDK. При его создании не пострадал ни один разработчик. Ах да, с 1 апреля! :D

Поговорим о том, какие инструменты хотелось бы иметь при описании бизнес-процессов. Инструментов BPMS (BPM systems) много, но выбрать то особо нечего

Ниже перечислим некоторые важные инструментальные возможности некоторых сред моделирования процессов (в основном АРИС-ARIS и MS visio).

Уточнения. BPM (business process management, управление бизнес-процессами) - это тот, который из области системной инженерии (SE), который почему-то теперь называют BPA (анализ). Он же CASE, где S= "system" (не "software").

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

Задача

Она очень простая. Нужно простым образом формализовывать процессы, нас окружающие. Так формализовать, чтобы модели процессов были адекватны реальным процессам, но чтобы их визуализацию хоть как-то понимало большинство людей, первый раз слышащих слово "BPM". Формально "интуитивно понятных" BPM-нотаций - много (также как много рекламно-маркетингового шума о BPM), но взять особо нечего. Однако здесь важна не только сама нотация (IDEF\VAD\EPC\BPMN\UML и т.п.), а механизмы ее представления на экране: слои, вариативность "точек зрения" (view-шек, представлений) и т.п. На мой взгляд, лучшим вариантом пока остается EPC (Event-driven Process Chain), но не суть, - представленные ниже подходы могут применяться к другим нотациям.

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

1. Подходы к визуализации диаграммы

1.1 Слои модели

Они позволяют управлять сложностью внутри одной модели (схемы). Например, введем три категории: Документы (входящие и исходящие), функция, ресурсы (роли и инструменты). Для каждой категории - свой слой.

Нарисовал нам наш архитектор (специалист по моделированию процессов) схему:

Рис. 1 Процесс оформления заявления

Visio Stencil Library for EPC - не нашел, поэтому "как то так" (штатная EPC - вообще "никакая").

Смотрят пользователи (Работник, Начальник, бизнес и системные аналитики) на схему и понять не могут, что нарисовано то и как этот процесс работает. Соглашение о моделировании прочитали, обучающие ролики посмотрели, но все равно не понятно.

Путь к пониманию - это упрощение схемы, например, будем отключать слои. В правильном инструменте (BPM-Tool) должны быть кнопки управления слоями - категориями. По кнопке "отключить ресурсы" - будет скрыт слой "ресурсы", в котором показаны объекты схемы (модели) типа "Роль" {Работник; Начальник} и Инструмент {MS Word}. Уже схема стала менее нагруженной (правой части не стало).

Далее отключаем слой "Документооборот" (docflow) и остается только последовательность действий (workflow, Process Flow), который говорит, что нужно провести всего две операции.

По мере появления ясности подключаем слои (кто исполнитель и какие документы на входе и выходе каждой функции \ операции). Когда схема большая (перегруженная) отключение слоев может творить "чудеса" в плане облегчения восприятия процесса. Иногда достаточно увидеть несколько представлений "одного и того же" (т.е. "те же самые, только в профиль") чтобы понять и нотацию и саму логику схемы, а если для этого достаточно нажать несколько кнопок (фильтров категорий), то путь к пониманию резко сокращается.

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

Пример такой реализации возможен в MS Visio:

Рис. 2 Управление слоями в MS Visio

Инструмент управления слоями, как управление сложностью - давно норма в векторных графических редакторах, ГИС и других CAD-системах, например, AutoCAD.

1.2 Плавательные дорожки

Swimlane позволяют группировать процесс по разрезам "Исполнители" и "Инструменты" (в общем случае - в разрезе любой иной категории объектов).

Применительно к Рис. 1 "Процесс оформления заявления": отключили слой "документы", а оставшуюся часть (функции и ресурсы) представили в виде одной или двух Swimlane (опять же "по кнопке").

Рис. 3 Swimlane по ролям в горизонтальной плоскости

Применительно к рассматриваемому случаю возможны следующие комбинации Swimlane:

- две одинарные (горизонт, вертикаль) по ролям;

- две одинарные (горизонт, вертикаль) по инструментам (часто в разрезе баз данных показывают);

- две двойные, "шахматка", таблица (горизонт - роли, вертикаль - инструменты и наоборот).

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

Основная проблема "дорожек" в том, что когда "дорожки" не нагруженные, то "съедается" основная часть листа и плотность "упаковки" объектов в модели процесса становится мизерная (КПД бассейна, где загружены только две дорожки, а остальные пустые - низкое).

1.3 Объекты модели и их атрибуты, свойства

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

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

В Visio это могут быть данные фигуры и таблица свойств фигуры (ShapeSheet). Еще интереснее свойства хранить в отдельном файле Excel , например, связанном с visio (штатная функция visio). Такой подход позволяет иметь репозитарий свойств объектов в файле Excel и соответственно обширные инструменты поиска, сортировки и т.п. Любой BPM инструмент, включая АРИС, не имеет таких развитых возможностей для анализа как Excel , поэтому выгрузка в Excel интересуемой пользователя атрибутики была бы важным элементом любого BPM-инструмента.

При просмотре схемы процесса должна быть возможность выделения объекта и просмотр атрибутов схемы и ее объектов (с наложением фильтров, т.к. иначе будет избыток).

1.4 Задание своей нотации (на примере новой ЕРС ver. 2)

Посмотрим на примере нотации ЕРС. Что же в ней улучшить? Все улучшения запишем в гипотетическую ЕРС2 нотацию.

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

Вообще, от workflow (схема алгоритма) ЕРС отличается в основном двумя параметрами: наличие указания ресурсов и документов (материалов) и иное задание условия разветвления алгоритма (ветвление по условию). Использование элемента "событие" - как указание результата, вместо "да" и "нет" - более функциональное и позволяет кроме того сократить номенклатуру графических примитивов. Событие - как "что-то произошло" и событие - как результат проверки условия.

Как показано в п. 1.1 "Слои модели": выделяем зону docflow, EPC-workflow и ресурсную зону. Docflow, а также любые другие входы и выходы функции (включая материалы, заготовки, полуфабрикаты и конечные продукты) - отображаем слева от функции (отдельная стрелка для всех входов, отдельная для всех выходов) с соответствующим направлением движения, а все ресурсы - справа от функции (без направленных коннекторов). Это позволит иметь стандартный "взгляд" на процесс и сразу фокусироваться на конкретной зоне.

В ЕРС2 будет классификация моделей: приведенная и мультиресурсная. В приведенной схеме будет к каждой функции привязано не более одной роли (инструмента), чтобы была однозначность по исполнителю (инструментарию), что важно не только для анализа, но и при построении Swimlane (каждому "пловцу - исполнителю" по выделенной дорожке).

Возможность задания своей нотации в инструменте моделирования означает подсказку (блокировку) при некорректном построении модели, как в момент отрисовки, так и через проверочный отчет построенной диаграммы. Например, в ЕРС2 предусматриваются следующие типы коннекторов: для входящих сущностей (входящие документы, материалы-заготовки), для выходящих (исходящие документы, продукты операции), соединитель потока (функции, события), соединитель ресурса. В объекте "функция" предусматриваются три "Connection Point" (visio):

- вверху и внизу объекта "функция" (и "события") - для указания структуры потока (очередность действий, событий);

- слева в овале "функция" два коннектора: один вход, второй выход (общие для docflow и потока материалов и т.п.);

- справа два коннектора: для исполнителя функции и инструмента, который используется для реализации функции.

Такой подход позволит легче читать схему ЕРС, сегодня же "глаза разбегаются", когда видишь паутину и вперемешку разбросанные а) "роли" - и слева и справа функции и б) "документы" - и слева и справа функции.

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

Вопрос: кроме как в visio, где можно задавать новые нотации и делать проверки на соответствие (валидность), аналогичные показанным выше?

1.5 Из таблицы - схему, а из схемы - таблицу

Если посмотреть на ЕРС схему (рис. 1), то видно, что она однозначно задается таблицей. Поля таблицы: вход, выход, функция, исполнитель, инструмент. Заполнили табличку, нажали кнопку "построить" - и схема сгенерировалась. Справедливо и обратное: по нарисованной схеме можно построить адекватную табличку без потери информации (lossless).

Механизм "Из таблицы - схему" в ARIS \ ARIS Express называется Smart Designer. Только он не умеет строить ветвление процесса. На всякий случай: поиск по "ARIS Smart Designer EPC", закладка "картинки".

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

Можно предусмотреть в таблице отдельное поле "полное описание функции" с подробным (большим, т.е. не влезающим в надпись) описанием операции, отображаемое на диаграмме в виде, например, всплывающей подсказки (или в отдельном окне) при активации конкретной функции (при наведении мышью).

Концептуально изложенный подход близок к выделенной в АРИС нотации "табличная ЕРС" (см. "Нотация ЕРС в виде таблицы"), но здесь реализация в виде обычной текстовой таблицы, т.е. ближе к ARIS Smart Designer. Причем логику процесса также можно указать в составе таблицы, например, как ссылка на предшествующий объект (этого нет Smart Designer, но не сложно добавить "что-то" для ЕРС2). Таблицу можно вставлять в текстовые регламенты word и макросом (VBA) генерить схему процесса ("не отходя от кассы") с дублированием конечно в общем каталоге моделей.

В теме автоматического создания диаграмм из таблицы (особенно Excel) нельзя обойти MS Visio Data Visualizer. Как обычно, - идея "на отлично" (идея далеко не новая), но реализация Видимо в погоне за максимальным универсализмом "выплеснулся ребенок BPM". Я ожидал увидеть что-то такое же простое, функциональное (мощное) и BPM-ориентированное как ARIS Smart Designer. Может это впечатление сложилось из-за отсутствия мастера автопостроения EPC. Кроме того, исключительная модель по подписке не позволяет популяризацию инструмента.

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

1.6 Из скрипта - схему, а из схемы - скрипт

Подход аналогичный генерации схемы по таблице (см. п. 1.5.), только используется язык, наподобие plant uml \ dot (graphviz). Структурные схемы (другие с простой нотацией) и UML строить уже можно, но вот EPC (лучше EPC2, т.е. задание языком специфических правил нотации) и другие со сложной нотацией - нет (красиво не получилось).

Применительно к graphviz: в случае, когда репозитарий объектов хранится в Excel, можно автоматически генерировать схемы, используя инструменты типа: Excel to Graphviz (sourceforge.net).

Пример простого VAD из dot:
digraph g {

rankdir=LR;

node [shape = cds];

Step1 -> Step2 -> Step3 -> Step4;

}

Посмотреть схему можно, вставив код в окно "Online Graphviz Generator":

http://fiane.mooo.com:8080/graphviz/

Кстати, редкий Online Graphviz понимает несокращенный набор параметров спецификации.

Кратко: LR - говорит, что схема строится "слева - направо" (для EPC ставим "сверху - вниз"), cds - это код объекта в виде "кораблика" (VAD). Далее через "->" указывает последовательность процессов. Можно задавать последовательно-параллельные структуры, подписи и тип стрелок, добавлять объекты "исполнители", "продукты" и другие "VAD-примочки", но при этом код становится сложным, а отсутствие нормального управления надписью (перенос, вписывание в фиксированный размер объекта и т.п.) ограничивают применимость инструмента.

Применять подход "скрипт -> схема" можно в сочетании с табличным представлением: например, скриптом VBA читаем поля заполненной пользователем таблички бизнес-процесса (см. 1.5 Из таблицы - схему ) и генерируем dot-последовательность, которую "скармливаем" локальному генератору dot (Graphviz устанавливается на компьютер) или Online Generator. Прямо в word- документе под табличкой "Процесс такой-то" размещаем "кнопочку" и пользователю даем возможность просмотра в графике того, что он ввел в табличку (как он описал в табличной форме свой процесс).

Из "BPM-связанного" особенно удобен dot для построения графов переходов. Если в модели есть docflow с документами со многими состояниями, то без схемы переходов состояний понимание многочисленных переходов осложнено, особенно когда смена состояний документа размазана по многим листам схемы. В итоге заполнив табличку и "скормив" её генератору dot мы увидим всевозможные переходы из состояний. Например, для документа "Отчет" возможны следующие состояния: Шаблон отчета - Шаблон отчета заполнен - Отчет согласован в отделе 1 - Отчет согласован в отделе 2 - Отчет подписан первой подписью - Отчет подписан второй подписью - Отчет оправлен регулятору - Отчет принят регулятором (возможны различные переходы из состояний).

В теме автоматического создания диаграмм из "текстового описания языком" нельзя не упомянуть про Object Process Diagram (OPD) \ Object Process Language (OPL). Тезисы у Object Process Methodology (OPM) вроде как BPM-ориентированные, но поверхностное знакомство с ним породило уверенность, что эта методология намного дальше от "workflow \ business process" (народа), чем те же plant uml \ dot (graphviz). OPCloud доступен тут: https://sandbox.opm.technion.ac.il/

Если немного помечтать, то настоящий BPM - инструмент должен из любого текстового "процессного" регламента (порядка действий) строить схему процесса. Когда это появится, то загрузив в такую систему многостраничные регламенты (листов под 200-300) мы обязательно увидим противоречивость и неоднозначность этих "пухлых" регламентов (несмотря на это, по ним как-то все работают же).

2. Другое

2.1 Навигация по связанным моделям (каталог моделей)

При построении вложенных диаграмм (причем, возможно выполненных в разных нотациях, например, верхнеуровневые в VAD, IDEF0) необходимо иметь возможность перехода от одной к другой.

Обычно связанный набор моделей (и их объектов) называют репозитарий (репозитОрий). Часто в интерфейсе программы предусмотрено два окна: иерархическое дерево моделей (слева вверху) и окно диаграммы (основное). В идеале навигация по моделям должна быть трех видов:

- по дереву моделей (treeview );

- по кликабельным объектам схемы (детализация - проваливаемся в низ, кнопка "выше" - переход к верхнеуровневой модели);

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

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

2.2 Разные фишки и отчеты по атрибутике

Поиск по названиям моделей, атрибутам. Задание правил отбора, например, по диапазону значений последнего редактирования модели. Выгрузка данных фильтрации \ сортировки во внешний файл (отчет), причем разного формата (например, excel для анализа, pdf для презентабельности) и т.п.

Правила работы с одноименными объектами (разрешение конфликтов), например, при наименовании нового объекта система смотрит - использовался ли одноименный объект и при выявлении такового предложит варианты, например, подтвердить или переименовать. У объекта в терминах АРИС только один Definition (Определение объекта, образ), но сколько угодно Occurrence (Отображение объекта, экземпляры на схемах).

2.3 Специфические отчеты

Отчеты могут быть разнообразны (зависит от воображения), но в первую очередь, нас будут интересовать выгрузки в распространенные формы. Универсальный генератор отчетов "на все случаи жизни" видимо проблема, но инструменты создания отчетов должны быть изначально в среде моделирования.

Для примера рассмотрим матрицу ответственности\ участия RACI. Требуется автоматическая генерация усеченной RACI-матрицы (здесь показано только для участников процесса, но часто плюс владельцы процесса) по имеющейся, например, VAD-диаграмме (value added chain diagram). Набор ключевых "мега процессов" компании показан в виде VAD и нужно по ним построить (синхронизировать) матрицу участников (RACI по одной только роли "участник процесса").

Рис. 4 Построение RACI матрицы

Алгоритм построения таблицы на VBA Visio\Excel может быть следующий:

1) Создаем в таблице Excel новую строку и в поле "Ключевые процессы" подставляем значение с активного листа visio из объекта типа "название мега процесса".

2) Далее циклом пробегаем по всем VAD-элементам схемы (листа) и через связь (объект "соединитель" для связки с объектами "исполнитель") находим связанные объекты типа "исполнитель" (участник подпроцесса).

3) Находим соответствующее название подразделения в шапке таблицы и на пересечении с процессом ставим символ участия (признак).

4) Переход к следующему листу visio.

Когда в организации десятки подразделений и около сотни "мега процессов" (их выделение достаточно субъективно), то задача синхронизации схем мега-процессов и матрицы участия подразделений в таких ключевых процессах становится достаточно трудоемкой.

2.4 Упаковка необъятной схемы процесса в печатный лист

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

2.5 Разное

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

Авто-размещение объектов на схеме: набросал невпопад объекты на лист (главное правильно связи указать и никого не забыть) и нажал кнопку: "расположить как надо" и система сама оптимально и красиво разместила объекты на схеме (в visio функции выравнивания и распределения фигур).

Открытые стандарты хранения и экспорта \ импорта (внешний графический импорт \ экспорт как минимум в visio), как самих графических объектов модели, так и их атрибутов. К сожалению, тот же MS visio так и не научился нормально экспортировать схемы в pdf и svg (например, всплывающие подсказки).

Изменение дизайна графического примитива для любого объекта нотации, расширение нотации, передача новых шаблонов в другую аналогичную систему, добавление новых атрибутов объектов (новых полей) и многое другое.

Заключение

Устаревшие подходы, реализованные в "современных" платных инструментах моделирования не адекватны времени. За механизацией пришли модные: "информатизация", потом "автоматизация", а теперь и "цифровизация" (аж Digital Transformation / digital disruption и совсем "свежий" Digital process Automation), но возможности инструментов моделирования процессов за три десятка лет почти не изменились. Функциональность древних ARIS, BPwin и т.п. практически не осовременилась в современных BPMS, несмотря на то, что интерес к классическому моделированию процессов постоянно растет, т.к. проблема замены текстовых регламентов на что-то прогрессивное - в целом так и не решена (диаграммы рабочих процессов не заменили текст). Имитационное моделирование и исполняемые модели (также направления, process mining, enterprise architecture - ЕА и др.) - не в счет, рассматриваем "классическое моделирование процессов" - оно же просто "формализация процессов".

Дождаться Open Source системы, в которой было бы реализовано указанное выше, - в обозримом будущем - маловероятно, поэтому, направление улучшайзинга для себя вижу как связку: visio VBA (core, графика) + Excel (как репозитарий для хранения атрибутов моделей, а в будущем и атрибутов графических объектов, инструменты аналитики) + web (publisher & collaboration).

Динозавр - монстр АРИС до сих пор остаётся продуктом 1 в данном сегменте, несмотря на то, что он "заморозился" во времени (в части toolset) и ничего нового в этом направлении не предлагает. АРИС (1994г) и многочисленные visio-надстроенные инструменты (Business Studio, BPM-Х, Orbus iServer и десяток аналогичных) хорошо показали саму концепцию моделирования процессов, которая неизменна десятилетиями. Концептуально подходы понятны, но вот для построения моделей процессов из free взять нечего: через BPMN описать сложные процессы компании - это утопия, если нужно чтобы пользователь понимал нарисованное. Вроде бы удобный трамплин для амбициозного стартапа

Если в CASE, где S="software", еще наблюдается вялотекущая "движуха", например, UML-UML2- SysML или "всяко исполняемое" (no code\ low code), то направление CASE, где S="system" в части BPM (не EA), - фактически "замерло на месте", а робкие попытки, что методологического плана, что инструментального - прежде всего Open Source инструменты "классического" моделирования процессов - скорее отождествляются термином "застой". Правда может я чего-то не заметил.

Немного поутихнет мода на BPMN2 (фетиш в плане замещения нотации ЕРС) и мы вернёмся к "вечному", к классическим подходам BPM, т.к. другого ничего пока так и нет (задачу описания небольших процессов - не рассматриваем). Вернувшись к исходной точке описания процессов, следует смотреть в сторону чего-то интуитивно понятного "простому смертному": бухгалтеру, кассиру, секретарю и т.п., т.е. не программисту. Скорее всего, вернемся к "старине" ЕРС (т.е. фактически к "разбитому корыту") и начнем двигаться к нотации "ЕРС+" (показано на примере ЕРС2) и более гибким (см. предложенные выше фишки) и открытым (free, Open Source) инструментам моделирования. Ориентация на человека, а не машину - ключевой вектор развития. Нотации и инструменты должны быть более "человечными", схемы процессов должны создавать не "специально обученные люди", а сами участники процесса, возможно, даже не подозревая об этом и непосредственно не рисуя процессы.

В 2000-ном году мной использовались ровно такие же подходы и ровно те же инструменты моделирования (основные: ARIS toolset, MS visio), что и сейчас, но тогда была настолько интенсивная "движуха в мире ВРМ", что казалось "вот-вот и прогресс всё поменяет", но это оказалось иллюзией. "Старику ARIS" (в части классического моделирования процессов) на пенсию бы (не смотря на добавленные круглую цифру 10 и магическое слово "cloud"), но похоже перемены придут еще совсем не скоро и светлое будущее обычного BPM откладывается

Редакционное уточнение. В предыдущих статьях не скупился на внешние ссылки. После этого статья обычно блокировалась хабро-модераторами и потом я упорно им доказывал, что приведенные ссылки не рекламного характера (в основном ссылки то антирекламные были), но при этом всё равно часть ссылок приходилось удалять (видимо принцип: "не вашим - не нашим"). Поэтому, "спокойнее" - с минимум ссылок, а "ищущий" сам загуглит по ключевым словам.