Hola, Amigos! На связи Саша Чаплыгин, Flutter-dev компании Amiga.

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

Это статья от автора Лейги Джаретт, продуктового менеджера Google по направлению Flutter. Материал посвящен последним достижениям и будущим приоритетам в улучшении Flutter, как инструмента для разработки iOS-приложений. Оригинал статьи можно найти по ссылке.

Если вы разработчик на Flutter или интересуетесь мобильными приложениями, сайтами, аналитикой в IT, то приглашаю в наш телеграм-канал Flutter.Много. Там мы пишем о Flutter, а еще делимся кейсами, полезными подборками и актуальными вакансиями. Присоединяйтесь!

Почему разработчики со всего мира любят Flutter?

С момента запуска в 2017 году, Flutter быстро набрал популярность среди разработчиков iOS-приложений. «Разработчики по всему миру обожают Flutter», — говорит Лейги Джаретт. С помощью Flutter можно один раз написать код и реализовать приложения на iOS, Android и десктоп. Это привело к появлению огромного числа пользователей и более чем миллиону приложений, которые созданы на Flutter.

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

Какие улучшения уже внедрены во Flutter и какие изменения ждут iOS-разработчиков в ближайшем будущем? Рассказываем в этой статье.

Известные iOS-приложения на Flutter

Flutter добился успеха в различных отраслях и категориях iOS-разработки. Крупные компании, такие как BMW, Sonos и Nubank, создали свои приложения на Flutter.

Технологические гиганты, такие как WeChat и PUBG MOBILE, используют Flutter для поддержки более миллиарда активных пользователей. Небольшие компании также смогли извлечь выгоду из быстрого цикла разработки на Flutter. Одним из примеров может служить BrickIt, который применяет машинное обучение для создания новых конструкций из блоков LEGO.

Apple и другие технологические лидеры признали iOS-приложения, созданные на Flutter. Wonderous, справочное приложение от Flutter, было номинировано на премию Webby в категории дизайна. Apple включила Reflection.app в свою престижную акселерационную программу. Приложение So Vegan несколько раз было удостоено награды Apple «Приложение дня».

Новые улучшения

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

Повышенная производительность
Impeller — механизм визуализации, который создан специально для Flutter — теперь является основным для работы с iOS. Разработка Impeller — это многолетний процесс для команды Google. Он решает ключевые задачи iOS-разработчиков, использующих Flutter — обеспечивает плавную графику и высокую производительность. С момента его запуска значительно повысилось качество приложений. Недавние улучшения механизма Flutter помогают сокращать время запуска и уменьшать размер приложений.

Impeller облегчает процесс добавления новых функций. Они включают поддержку изображений с широкой гаммой и пользовательские решения для визуализации. На конференции Flutter Forward продемонстрировали одно из таких решений — концепция поддержки 3D.

Улучшение процесса разработки
Компания Google осознает сложности, связанные с созданием и выпуском iOS-приложения. Для экономии времени разработчиков они внедрили новые инструменты и ресурсы, которые упрощают процесс. Теперь можно подключаться к iOS-устройствам по Wi-Fi для тестирования и отладки приложений. Также внедрена валидация в процесс выпуска приложения. Этот этап гарантирует выполнение всех необходимых действий перед публикацией приложения в App Store.

Разработана документация и обучающие материалы, чтобы помочь разработчикам освоить Flutter и создавать iOS-приложения. В базе знаний добавлены примеры на Swift и SwiftUI, подготовлены инструкции по переходу от Swift к Dart, от SwiftUI к Flutter и по добавлению Flutter в уже существующее iOS-приложение. Команда Google предоставили ресурсы для поддержки различных версий на iOS и использования расширений для iOS-приложений таких, как виджеты для домашнего экрана и экрана блокировки.

Обновление компонентов интерфейса в стиле iOS
Библиотека Cupertino предоставляет виджеты (элементы пользовательского интерфейса), которые напоминают SwiftUI и UIKit. Это поможет приложениям идеально адаптироваться к устройствам Apple. Для лучшего соответствия последним руководящим принципам дизайна iOS внесены существенные обновления в библиотеку Cupertino.

В Google учли наиболее популярные проблемы и добавили новые виджеты: CupertinoCheckbox, CupertinoRadio, CupertinoListTile. И поддержку проверки правописания в текстовых полях ввода.

Что касается кроссплатформенного дизайна, то команда Google внедрила адаптивные конструкторы в несколько виджетов Material. Это позволяет приложениям на Flutter гибко адаптироваться к дизайну Android и iOS. Для общих виджетов без адаптивных конструкторов созданы предварительные руководства с примерами кода для адаптации виджетов или их свойств.

План развития

В стремлении сделать Flutter более удобным инструментом для разработчиков iOS, в Google сосредоточились на нескольких ключевых направлениях.

Интеграция в экосистему Apple
Flutter-разработчики должны иметь возможность без труда использовать API от Apple в своих приложениях. Это позволит создавать увлекательные приложения, объединяющие все преимущества Apple.

Несколько месяцев назад был запущен FFIgen. Этот инструмент позволяет генерировать связи для вызова API от Objective-C и Swift прямо из кода Dart. Некоторые приложения уже применяют FFIgen для вызова API от Apple. Но все же существуют некоторые ограничения. Инструмент активно улучшают и добавляют поддержку асинхронных обратных вызовов и совершенствуют взаимодействие со Swift.

Велика важность расширений для приложений в рамках экосистемы iOS. Поэтому Google разрабатывает метод создания пользовательского интерфейса для некоторых расширений на Flutter. Это даст возможность разработчикам использовать компоненты из своего приложения, созданного на Flutter, для дизайна интерфейса их расширения. Но данный подход не подойдет для всех видов расширений. Например, у виджетов WidgetKit есть строгие ограничения API. Тем не менее, он подойдет для других распространенных расширений, таких как Share или iMessage.

Кроссплатформенный дизайн
Развертывание приложений на различных платформах требует дизайнерских решений. Необходимо найти баланс между кастомизацией компонентов пользовательского интерфейса в соответствии с брендом и соблюдением стандартов платформы.

Поэтому команда Google ищет способы улучшить процесс дизайна и создания приложений на Flutter. Во-первых, они хотят сделать стандартные компоненты пользовательского интерфейса Flutter более гибкими. Таким образом, разработчики смогут быстро адаптировать виджеты под свои системы дизайна. Во-вторых, Google хочет использовать больше автоматизированных адаптаций, чтобы приложения Flutter выглядели естественно как на iOS, так и на Android.

Процесс разработки
Цель Google — улучшить процессы iOS-разработки на Flutter. Одним из основных фокусов является уменьшение времени построения для увеличения производительности разработчиков. Также в планах удовлетворить давние пожелания, например, возможность переименования приложения Runner. И наконец, продолжить приоритизировать улучшение производительности и общего качества работы на iOS.

Как вам статья? Пишите в комментариях было ли вам полезно! И подписывайтесь на наш телеграм-канал Flutter.Много, чтобы одним из первых узнавать о новых статьях.

Привет, Хабр! Сегодня мы продолжим знакомить вас с инструментами, используемыми атакующими для горизонтального перемещения, а также способами детектирования их эксплуатации. В прошлом материале нами был рассмотрен достаточно известный инструмент PsExec, а сегодня мы поговорим о SMBExec и AtExec — других не слишком сложных, если говорить об исполнении атаки, но достаточно распространенных среди злоумышленников инструментах.

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

SMBExec

SMBExec — один из скриптов набора Impacket, работа которого, также как и в PSExec, основывается на удалённом создании сервиса и его последующем запуске.

Как известно, сервис запускает тот исполняемый файл, что указан в его конфигурации, вместе с различными параметрами. При использовании SMBExec с каждой запускаемой командой создаётся новый сервис, в конфигурацию которого выставляется путь до, например, cmd.exe и параметры к нему (например, whoami).

$ python3 smbexec.py Domain/Username:password@10.150.x.16  Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation  [!] Launching semi-interactive shell - Careful what you execute C:\Windows\system32>ipconfig  Windows IP Configuration Ethernet adapter Ethernet0:     Connection-specific DNS Suffix  . :    IPv4 Address. . . . . . . . . . . : 10.150.x.16    Subnet Mask . . . . . . . . . . . : 255.255.255.0    Default Gateway . . . . . . . . . : 10.150.x.1  C:\Windows\system32>whoami nt authority\system

Можно выделить два фундаментальных этапа работы SMBExec:

1. Запрос к RPC интерфейсу svcctl, ответственному за удалённое управление сервисами;

2. Создание самого сервиса, который ответственен за непосредственный запуск команды.

Теперь посмотрим, как именно можно отследить его эксплуатацию.

В поисках артефактов

Составить единое и качественное правило детектирования, которое бы покрывало все случаи использования SMBExec только на основе логов создания сервиса, проблематично, так как суть атаки заключается в возможности запуска исполняемых файлов с аргументами. А это выливается в однострочные реверс-шеллы и команды. Если же строить детектирование на основе логов, содержащих запуск cmd.exe или powershell.exe, то неизбежной будет проблема «игры в крота», где начнут появляться другие возможности для запуска зловредной команды (список LOLBAS тому подтверждение).

Поэтому при детектировании SMBExec стоит учитывать не только события создания сервиса, но и события доступа к RPC (запрос Named Pipe svcctl и попытку вызова RPC), которые показывают, что сервис был запущен удалённо, а не локально. Эти события представленны ниже:

• EventID 4697 — A service was installed in the system;

• EventID 5145 — Detailed File Share;

• EventID 5712 — A Remote Procedure Call (RPC) was attempted.

В событии создания сервиса EventID 4697 необходимо определить какой по типу сервис сейчас создаётся — «родной» для Windows или от третьей стороны. Это можно сделать, посмотрев на поле Service Type. В таблице ниже под спойлером показаны возможные значения типов сервисов:

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

Per-user сервисы запускаются в контексте пользователя как часть пользовательского сеанса в фоновом режиме, когда он входит в систему.

Для создания экземпляров per-user сервисов система использует шаблоны. Если шаблон именуется, к примеру, UnistoreSvc, то к названию экземпляра будет добавляться еще и некоторое рандомное значение, например, UnistoreSvc_bd00d6ea.

У шаблонов, как и у экземпляров есть свои собственные типы:

• для шаблонов — 0x50 (individual process) и 0x60 (shared process);

• для экземпляров — 0xD0 (individual process) и 0xE0 (shared process).

Опираясь на вышеперечисленные типы, в контексте детекта нас будут интересовать сервисы с типом 0x10 и 0x110.

Так мы можем отделить все встроенные в Windows сервисы и смотреть только на пришедшие «извне». Теперь наша задача состоит в разделении сервисов, которые созданы как легитимным софтом, так и атакующими. Здесь как раз и возникает проблема ложных срабатываний. Чаще всего легитимный софт не использует параметры к собственным сервисам, и таким образом можно избежать части ложных срабатываний. Также их можно избежать, если применить корреляцию по полю Username между событиями использования RPC и событием создания сервиса в тот же момент.

Другой возможный вариант, когда в созданных сервисах могут быть изменены команды, что не будет зафиксировано в событии EventID 4697. Об этом свидетельствует документация Microsoft:

Эта возможность рождает другой метод Lateral Movement, который мы рассмотрим чуть позже.

Создание и возможное изменение сервисов отслеживается по ветке реестра HKLM\System\CurrentControlSet\Services, в которой содержится информация обо всех сервисах машины. Каждая подветка — это определённый сервис, где находится ключ ImagePath, содержащий в себе полную команду для сервиса.

Детектировать такое поведение можно как с помощью Sysmon, так и с помощью выставленного заранеe SACL и событий из журналов EventLog. Мы приведем сразу оба варианта. Пример лога от Sysmon c EventID 13 — Registry value set показан на рисунке 3:

При настройке SACL в журнале Security изменения значения ветки реестра можно отследить по событию 4657 — A registry value was modified (рисунок 4):

Таким образом у нас есть возможность детектировать не только изменения в сервисах, но и создание новых. Данные события можно также использовать как альтернативу событиям EventID 4697.

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

Удалённое создание сервисов

Как и в случае с PsExec, чтобы отследить факт удаленного создания сервиса, нужно обратить внимание на событие с EventID 5145 (Detailed File Share).Это событие доступа к именованному каналу с именем svcctl — интерфейсу , который позволяет управлять сервисами на удаленном устройстве. Однако оно имеет свой недостаток, так как формируется только в случае подключения к Named Pipe через SMB посредством IPC$. Тогда как подключение напрямую по RPC совершенно игнорирует. Подробнее об этой проблеме можно прочесть в статье RPC и способы его мониторинга.
Данный недостаток можно исправить с помощью механизма RPC Filtering , после настройки которого появившиеся события скажут нам о подключении к менеджеру сервисов как с помощью RPC, так и с помощью SMB.

rpc filter add rule layer=um actiontype=permit audit=enable add condition field=if_uuid matchtype=equal data=367abb81-9844-35f1-ad32-98f038001003 add filter

netsh -f rpcauditrule.txt

Следовательно, при использовании svcctl мы можем получать логи, подобные событиям с EventID 5145 (Detailed File Share), но они будут формироваться, даже если пользователь подключился по RPC напрямую — EventID 5712 (A Remote Procedure Call (RPC) was attempted).

Теперь, когда мы определились с событиями, которые будем использовать, нам нужно собрать их воедино и построить возможное правило детектирования.

Итоги по событиям и построение правила детектирования

При построении правила детектирования эксплуатации SMBExec мы воспользуемся следующими событиями:

• Событие удалённого запроса к менеджеру сервисов, доступное нам благодаря RPC Filtering (EventID 5712):

• Событие создания сервиса (EventID 4697):

Поле Service File Name в стандартных ситуациях должно содержать только путь до исполняемого файла и аргументы к нему. Во время атаки поле содержит команду для cmd.exe, скрывающеюся за переменной %COMSPEC%.

Для удобства мы также попробуем фильтровать типы запуска сервисов, которые будут бесполезны атакующему при Lateral Movement.

Таблица от Microsoft, покажет нам какие типы запуска сервисов можно отбросить при поиске атаки.

И мы увидим, что единственные приемлемые для атакующего типы запуска — 2 и 3.

Перейдем к детектированию эксплуатации SMBExec.

Возможное правило детектирования

Исходя из приведённых событий, ниже представлено псевдо-правило для обнаружения использования SMBExec по созданию им сервиса и подключению к svcctl удалённо:

SELECT * FROM EventCode=5712 WHERE  ((Name, LogonId)) IN ( SELECT (Account_Name, Logon_ID) FROM EventCode=4697 WHERE Service_File_Name IN ("*.exe *", "*.exe\ *", "%*% *") AND Service_Start_Type IN (2, 3) AND Service_Type IN ("0x10", "0x110") )

Данное правило будет учитывать только сервисы, не встроенные в Windows с автоматическим или ручным типом запуска.

А теперь давайте рассмотрим другой инструмент для горизонтального перемещения — AtExec.

AtExec

AtExec — также один из скриптов набора Impacket, чья работа основывается на создании запланированных задач (scheduled tasks). Планировщик задач может управляться удалённо, и, конечно, посредством него существует возможность создавать запланированные задачи. Они, в свою очередь, исполняют команды, которые отображены в примере под спойлером:

$  python3 atexec.py DOMAIN/username:password@10.150.x.16 whoami Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation  [!] This will work ONLY on Windows >= Vista [*] Creating task \WVhfEDnX [*] Running task \WVhfEDnX [*] Deleting task \WVhfEDnX [*] Attempting to read ADMIN$\Temp\WVhfEDnX.tmp [*] Attempting to read ADMIN$\Temp\WVhfEDnX.tmp nt authority\system

Работа инструмента AtExec выглядит следующим образом:

1. Запрос к RPC интерфейсу atsvc, ответственному за удалённый запуск планировщика задач;

2. Создание запланированной задачи с произвольным именем, которая в последствии может использоваться для запуска различных команд или исполняемых файлов.

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

Возможные сложности

Сложность обнаружения эксплуатации данного инструмента заключается в большом шансе ложных срабатываний, ведь инструмент использует возможности Windows, применяемые легетимным ПО. Эмпирически получилось установить определённую последовательность логов, фиксирующую создание, запуск и завершение задачи, которую выполнил злоумышленник по порядку, характерному только для атаки.

К этому мы можем добавить обращение пользователя по RPC к Named Pipe с именем atsvc, отвечающее за функционал менеджера задач. Но необязательно, поскольку детектирование в любом случае основывается на логах Scheduled tasks , а создать задачу через RPC может любое легитимное ПО.
Для детектирования мы будем использовать события журнала Applications and Services Logs -> Microsoft -> Windows -> TaskScheduler.

Теперь давайте подробнее рассмотрим логи TaskScheduler и узнаем какая информация будет полезна при построении возможного правила.

Идем по следам

Для обнаружения эксплуатации инструмента AtExec нами были выбраны наиболее информативные события, а именно:

• Событие EventID 106 — Task registered:

• Событие EventID 100 — Task Started:

Созданная задача сразу же запускается от имени NT AUTHORITY\SYSTEM. Но мы будем учитывать тот факт, что контекст запускаемой задачи может изменяться.

• EventID 110 — Task triggered by user:

• EventID 102 —Task completed:

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

• EventID 141 — Task registration deleted:

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

Возможное правило детектирования

Основываясь на событиях, приведенных выше, было составлено псевдо-правило:

SELECT * FROM EventCode = 100 WHERE (TaskName) IN ( SELECT TaskName FROM EventCode = 110     WHERE User = "System" SELECT TaskName FROM EventCode = 102         WHERE User = "NT AUTHORITY\SYSTEM" SELECT TaskName FROM EventCode = 106 WHERE User != "NT AUTHORITY\SYSTEM" )

Логика детектирования здесь следующая: если ScheduledTask создается от имени обычного пользователя, а после запускается от имени системы, и, при этом, это один и тот же ScheduledTask, то срабатывает алерт.

Заключение

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

Надеемся, что статья оказалась вам полезной! Оставляйте ваши комментарии ниже и пишите вопросы 🙂

Авторы:
— Черных Кирилл (@Ruucker), аналитик-исследователь киберугроз;
— Мавлютова Валерия (@IceFlipper), младший аналитик-исследователь киберугроз.

Почти четверть века назад я занимался моделированием интерференции и голографии в оптических нелинейных средах — попросту говоря, фотополимерах — а сегодня в качестве хобби разрабатываю открытый InSAR процессор PyGMTSAR. Если вам покажется странным, почему в качестве хобби, то это просто — потому, что я могу сделать продукт лучше, чем аналоги от НАСА (JPL ISCE) и Европейского космического агенства (SNAP), а вот гранты на разработку они выдают гражданам США и Евросоюза (коим я не являюсь). Что касается российской науки, то лишь спустя десятилетие после окончания университета я случайно узнал (гугл показал ссылку на меня же в запросе, связанном с интерферограммами в фотополимерах), что моя магистерская работа заняла первое место во всероссийском конкурсе, где ННГУ им. Лобачевского из Нижнего Новгорода, кажется, и вовсе не появлялся (хотя после выпуска и завершения конкурса я еще работал в университете, я даже не знал, что мою работу отправляли на всероссийский конкурс). Наверное, это вполне объясняет, почему же мне интересна тема InSAR. А вот к фотополимерным принтерам, которые с тех пор стали мейнстримом, душа не лежит и мне гораздо интереснее именно теоретическая часть моей давней работы, которая и является основой спутниковой интерферометрии. На хабре я уже публиковал серию статей на русском языке по обработку данных с радарных спутников Sentinel-1, а для тех, кто хочет подробнее, предлагаю обратиться к моей электронной книге на английском. Она доступна во многих онлайн издательствах, включая Амазон, а также значительная часть контента опубликована в открытом PDF (также другие главы можно найти в моих постах на линкедин, когда я выкладывал драфты в процессе написания книги).

Аннотация

Серия книг «PyGMTSAR: Sentinel-1 Python InSAR» послужит вам ключом для освоению вселенной спутниковой интерферометрии для данных спутников Sentinel-1 с помощью открытой Python-библиотеки для InSAR, PyGMTSAR. Написанные разработчиком, эти книги служат практическими руководствами по работе с PyGMTSAR в Jupyter ноутбуках или консольных Python-скриптах.

Книга «PyGMTSAR: Sentinel-1 Python InSAR. Введение» рекомендует Google Colab, бесплатный облачный сервис, как идеальную платформу для начинающих. Читатели могут исследовать применения PyGMTSAR для отслеживания сейсмической активности, изучения результатов извержений вулканов, оценки состояния инфраструктуры и прочих задач с помощью серии интерактивных блокнотов. Каждый блокнот сопровождается инструкциями для их адаптации к вашим проектам и обучения.

В руководстве также представлен Docker Desktop, популярная открытая платформа для контейнеризации. Docker-образы PyGMTSAR создают рабочее пространство, аналогичное локальной установке системы, позволяя проводить интенсивные вычисления на вашем локальном компьютере и на облачных хостах. Ноутбуки Google Colab доступны в докер образах, а также добавлены более ресурсоемкие примеры.

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

Студент вы, исследователь или профессионал с интересом к дистанционному зондированию и наблюдению за Землей, книга «PyGMTSAR: Sentinel-1 Python InSAR. An Introduction» обеспечивает вас вас необходимыми навыками и знаниями для работы со спутниковой интерферометрией на языке программирования Python.

Также смотрите

• Мои статьи на Хабре
• Работа с ГИС и ГЕО данными на LinkedIn
• Геологические модели и код на GitHub
• YouTube канал с геологическими моделями
• Геологические модели в виртуальной/дополненной реальности (VR/AR)
• PyGMTSAR InSAR Docker образы на DockerHub

Кому будет полезна статья?

— аналитикам и их руководителям, которые устали от бесконечного потока ad-hoc задач и хотят построить нормальный процесс работы;

— продактам, которые устали от того, что бизнес-заказчики двигают свои задачи вперед и нарушают планы продуктовой команды;

— бизнес-заказчикам, которые недовольны скоростью решения задач и отсутствием прозрачности в процессе их решения.

Коротко об авторах

Давид Мкртумян (Linked-in | FB | VK | Instagram)

Я работаю ведущим менеджером продукта в Авито и являюсь автором Telegram-канала Product Net, где делюсь своим опытом, оказываю карьерные консультации и помогаю продактам найти работу своей мечты. До этого работал продактом в AliExpress, Яндекс Маркете и 3 года развивал собственный бизнес.

Владимир Тепляков

Вова работает продуктовым аналитиком в Авито. У него больше 5 лет опыта в области анализа данных. Ранее работал в ГК ПИК, Везёт (нынче Яндекс.Такси) и Магнит. В свободное время администрирует Telegram канал «Дата-аналитика, и с чем её едят», где вместе с коллегами помогает начинающим аналитикам и делится профессиональным опытом.

В чем была проблема?

Если быть точным, то был целый букет проблем:

• Команде аналитики регулярно вкидывали срочные ad-hoc задачи в середине спринта.

• Бизнес-заказчики часто ставили своим задачам наивысший приоритет, в результате чего задачи продакта откладывались, от чего страдал весь продуктовый процесс.

• В спринт попадали непрогруммленные и плохо сформулированные задачи. В итоге на выходе заказчик получал не тот результат, который ожидал.

• Заказчики были недовольны сроком выполнения задач. Процесс был непрозрачным.

• Из-за всех вышеперечисленных проблем в команде постоянно возникали разногласия.

• Аналитик горел словно ведьма на костре инквизиции.

Что сделали?

1. Завели Google таблицу со следующими столбцами:

Задача

Указываем название задачи. При необходимости добавляем комментарии к ячейке с названием. К названию задачи прикрепляем ссылку на тикет в jira/трекер с подробным описанием задачи.

Типа задачи

• Исследование

• Выгрузка

• АБ-тест

Заказчик

Указываем имя заказчика, чтобы аналитик знал с кем связаться, в случае, если возникнут вопросы по задаче.

Приоритет

1. Высокий

2. Средний

3. Низкий

Нужен ли грумминг

Тут ставим чек-бокс – да/нет

Задача прогруммлена

Аналогично — да/нет

Нужно взять в следующий спринт

Так же чек-бокс – да/нет. Это также влияет на приоритет задачи.

Story points (SP)

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

Статус

• New – обсуждаются на регулярной встрече.

• In progress – в случае необходимости обсуждаются на регулярной встрече.

• Done – улетают в лист “Архив” в той же Google таблице, чтобы к ним можно было вернуться, если возникнет такая необходимость.

• Hold – улетают в архив, если больше месяца не берется в работу.

2. Поставили регулярную встречу для обсуждения аналитических задач

Состав участников

• Аналитик

• Продакт

• Проджект

• Маркетолог

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

Подготовка к встрече

Каждый участник накануне встречи вносит свои задачи в таблицу и прикрепляет к ним тикет в jira.

Ход встречи

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

После встречи

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

Каких результатов добились?

• Свели к минимуму количество ad-hoc задач на аналитику. Теперь это редкие, единичные случаи.

• Сделали процесс прозрачным для всех членов команды.

• Нормализовали нагрузку на аналитика.

• Больше не толкаемся локтями и не спорим, чья задача важнее.

• Уже полгода радуемся эффективной и слаженной работе в команде 😉

P.S.

На этом все. Если вам понравилась статья, то поделитесь ей с теми, кому она может быть полезна, и подписывайтесь на мой канал Product Net в Telegram. Там вы найдете больше материалов на актуальные вопросы, сможете влиять на темы будущих постов и получить помощь в трудоустройстве в топовые российские IT компании 😉

Эта статья о моем опыте импортозамещения в сфере сертифицированного измерительного оборудования, а именно использование приборов Bercut‑ETX 10G компании ООО «НТЦ‑Метротек». Полагаю, что информация в статье будет любопытна коллегам трудящимся в близких областях.

Здравствуйте, меня зовут Денис Шехалев. Работаю в сфере разработки систем радиосвязи, радионавигации, радиолокации и т.д. В профессиональных кругах известен под ником des00.

При разработке очередной системы связи с интерфейсами Ethernet, в ТЗ было обозначено обязательное требование: приемосдаточные испытания должны проводиться на сертифицированном измерительном оборудовании отечественного производства. Требовалось выполнить стандартные тесты оборудования Ethernet и провести метрологию оборудования радиосвязи на асимметричном радиоканале через порты 100/1000Мб/с.

При обращении в государственный реестр средств измерений для сетей Ethernet нашлись приборы компании «НТЦ‑Метротек» семейства Bercut-ETX, под номером 52143-12. По результатам изучения руководства по эксплуатации ДДГМ.030.000.001 РЭ Редакция 15, 2022 (запомним это!) было принято решение приобрести два прибора в разных конфигурациях.

Первый прибор для проведения измерений: RFC-2544, Y.1564, BERT, второй прибор RFC-2544, BERT, Пакетный джиттер, Генератор трафика, Приказ 870. Т.е. приборы предназначались для выполнения одностороннего/двустороннего BERT, тестов RFC-2544, Y.1564, Приказ 870 и т.д. при включенном шлейфе на одном из приборов.

Хочу отметить, что базовый прибор по сути болванка с минимальным набором инструментов. Все остальные инструменты и опции требуется покупать отдельно. Стоимость требуемых нам лицензий оказалась сопоставима по стоимости с базовой ценой приборов. Т.е. цена приборов выросла почти в 2 раза, а их итоговая стоимость составила, с учетом уровня цен 2022 года, цену приличного автомобиля. 🙂

Первые «звоночки»

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

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

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

Как показала дальнейшая эксплуатация она пригодилась еще много раз.

Первое обращение в саппорт

Чем меньше багов оставалось в собственном оборудовании, тем более явно проступали баги приборов. Полагаю, что не я один такой, кто считает сертифицированный прибор, априори рабочим и достоверным, поэтому в первую очередь ищет проблемы в собственном оборудовании, а не приборе. И вот, в очередной раз приборы заявили, что оборудование не работает, хотя статистика разрабатываемого оборудования не показывала проблем. В процессе диагностики выяснилось: один прибор не видит входной поток при двустороннем BERT. Причем не видит его настолько, что даже не работает счетчик принятых кадров. Выключение и включение прибора помогло, трафик пошел. Но после этого терпение закончилось и было обращение в саппорт с открытием кейса под номером 1374.

Начало саппорта

Началась процедура поддержки с обновления ПО, хотя это очень удивительно для приборов, купленных в 2022 году. Выяснилось, что на одном приборе версия ПО слишком далеко ушла от релизной прошивки версии 15. Т.е. в 2022 году, нам продали прибор, в котором залили старую прошивку. Даже если прибор был на складе несколько лет и его потом достали и продали, то полагаю, что компания уровня «НТЦ-Метротек», как минимум должна была выполнить «предпродажную» подготовку зная о том, что ПО обновляется.

Что интересно, прошиваются приборы очень своеобразно для 2023 года: прибор на котором есть оптические порты 1/10G, порт 1000/100/10, локальный порт Ethernet, USB прошивается через виртуальный COM-порт и Xmodem на скорости 57600б/с, поэтому обновление прошивки занимает 45 минут (запомним это!).

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

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

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

Глючили измерения: приборы не видели входной трафик или видели несуществующий трафик, не формировали выходной трафик, не выдерживали заданную скорость потока, не корректно отображалась статистика работы прибора, приборы плевали в сеть некорректные кадры (в режиме BERT прибор раз в секунду выдает кадр минимального размера, в котором DMAC = SMAC, а в поле данных нули). Да, некорректные кадры не влияли на работу теста, но в руководстве по эксплуатации упоминания этой особенности я не нашел. Разрабатываемое оборудование их отбрасывало, но диагностика того что же именно откидывает оборудование и почему, заняло значительное рабочее время. В итоге выяснилось, что оно работает абсолютно корректно, в отличии от приборов.

Все эти моменты обсуждались с саппортом, диалог с которым изначально строился на позиции «сам дурак, читай инструкцию». Да, отчасти они были правы, некоторые тесты я запускал не корректно, не прочитав внимательно руководство по эксплуатации.

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

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

Но самое главное, по мере использования ПО версии 22 внезапно выяснилось, что приборы потеряли часть своей функциональности. Напомню, ПО версии 15 на приборах позволяло выполнять тесты RFC-2544/Y.1564/BERT и RFC-2544/BERT/Приказ 870. А ПО версии 22 только Y.1564/BERT. На разумное обращение в саппорт, куда делись оплаченные опции, был получен ответ что с 2023 года приборы изменили свою функциональность, о чем указано в руководстве по эксплуатации ДДГМ.030.000.001 РЭ Редакция 16, 2023. Теперь есть отдельная прошивка Y.1564/BERT и отдельная прошивка RFC-2544/Приказ 870. Т.е. купленные лицензии работают, но, если вы хотите весь диапазон нужных вам тестов, перешивайте приборы каждый раз. Да, да, именно той самой процедурой которая длиться 45 минут через COM-порт.

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

Неожиданные открытия

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

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

Смирившись с тем что от саппорта толку ноль, а работу, уже по бета‑тестированию делать надо, решил откатить ПО приборов на версию 15 чтобы подготовить их к выездам на испытательные полигоны: сконфигурировать все нужные тесты и сохранить их профиль. Делать вручную это не удобно, поэтому я задействовал возможности протокола Telnet указанные в руководстве по эксплуатации. Тут я совсем забыл, что оказывается, на приборах, предназначенных для тестирования сетей Ethernet, в 2023 году, эта штука платная и лицензия Telnet была куплена только на один прибор. Но этого оказалось достаточно.

Какого же было мое удивление, когда выяснилось, что ПО версии 15, распространяемое в качестве стабильного релиза, если судить по логотипу компании не обновлялось с 2013 года. т. е. за 10 лет, доработок в ПО прибора не вносилось, глюки не правились. А если правились, но это не отображалось в лого компании, то это как минимум странно для компании такого уровня, как «НТЦ‑Метротек».

Во избежание недоразумений и обвинения меня в «фантазерстве», вот ссылка на облако, где выложены видео, отправляемые в саппорт компании «НТЦ‑Метротек».

Резюмирую свой опыт использования этих приборов.

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

Большинство багов возникали в момент включения прибора и запуска первого теста. Ну лень заниматься такими тестами отделу тестирования, наймите 10 пенсионеров на пару месяцев, дайте им по пенсии сверху, комнату с чаем, чипеньками и музыкой что бы попеть. Каждому дайте два прибора настроенных друг на друга и пусть они каждые 5-10 минут включают/выключают прибор и тыкают кнопки. Большую часть багов вы сразу найдете. За полгода почти ежедневного использования приборов они у меня глючили раз 50, не верю, что толпа тестеров-аксакалов не сможет выловить эти ошибки.

Резюмирую свой опыт общения с саппортом «НТЦ‑Метротек»

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

На текущий момент, получилось договориться с саппортом компании об отправке приборов (покупки 2022 года) в гарантийный ремонт, с предоставлением подменных приборов на время ремонта. Посмотрим, что же из этого получится. 🙂

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

Этой статьей, пусть и поданной в критической манере изложения, я пытаюсь призвать компанию «НТЦ-Метротек» к ответственности за свой продукт. Понимаю, что прибор сложный, что в нем куча программируемых чипов, но тем не менее отвечайте за свою продукцию. Выпустили сырой прибор на рынок, будьте добры обеспечить надежность его работы. Не можете обеспечить работоспособность прибора — отзывайте его, выкупайте обратно бесполезные лицензии и приборы. Продали приборы в одной конфигурации, так осуществляйте поддержку этой конфигурации в течении срока жизни прибора.

Да и в целом, меня удивляет тот факт, что руководитель проекта Bercut одобрил идею обеспечить приборы, с лицензированными инструментами и опциями, разными прошивками. Ну хорошо, все тесты не влезают в ресурсы ПЛИС, так храните все прошивки в приборе. Переключайте контекст за секунды. Но неужели даже мысли не возникло, что ждать 45 минут, если надо провести несколько видов тестов во время выезда, это как минимум не удобно?

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