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

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

Эта задача - про качество данных и очень напоминает тестирование. Так почему не использовать фреймворк тестирования pytest, и не написать тесты на каждый проверяемый аспект и для каждого типа файлов? Однако, есть небольшое "но". проверка должна быть реализована в качестве сервиса, чтобы встраиваться в более широкий процесс обработки пользовательских документов.

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

Практически повсеместно в производственных и коммерческих компаниях отделы ИТ сталкиваются со смешанной нагрузкой - часть “проектная”, часть “операционная”.

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

Понятно, что все ожидания внутренних клиентов от отдела ИТ должно выражаться в виде SLO (Service Level Objectives). Вот только количество сервисов и SLO со времененем растет, и сама задача контроля становится тяжелой рутиной.

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

В этой статье я хочу поделиться практикой постановки и внедрения S.M.A.R.T. (Specific, Measurable, Attainable/Achievable, Relevant, Time-bounded) целей для операционной части загрузки отдела. Как мы к этому подходили, какие результаты получили и какие побочные эффекты наблюдаем.

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

В нашем случае, стояла задача предварительного анализа (скоринга) документов по их содержимому. Верхнеуровневый процесс обработки документов построен с использованием MS Power Automate, поэтому конвертор нужно было реализовать в виде некоего облачного сервиса, доступного через HTTP.

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

Я недавно проводил исследование, в рамках которого было необходимо обработать несколько сотен тысяч наборов входных данных. Для каждого набора — провести некоторые расчеты, результаты всех расчетов собрать вместе и выбрать "лучший" по некоторым критериям. По сути это bruteforce перебор. Тоже самое происходит при подборе параметров ML моделей с помощью GridSearch.

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

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

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

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

Под катом я расскажу про:

• сбор отзывов на рекомендации
• выработку метрик для оценки качества рекомендаций
• построение цикла оптимизации модели
• полученные инсайты и новую модель

Всем, кто провел определенное время, поддерживая системы, знакомо чувство déjà vu при получении новой заявки: "вроде такое было, вроде решали, но как конкретно — не помню". Можно потратить время, покопаться в предыдущих заявках и постараться найти похожие. Это поможет: инцидент будет закрыт быстрее, а может быть даже удастся обнаружить глубинную причину и закрыть проблему раз и навсегда.

У "молодых" сотрудников, только присоединившихся к команде, такой истории в голове еще нет. Они, скорее всего, не знают, что аналогичный инцидент, например, произошел полгода-год назад. И решил тот инцидент коллега из соседней комнаты.

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

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

Часто в рамках проверки Pull Request, помимо, собственно, code review, возникает необходимость проделывать набор рутинных проверок. Некоторые проверки могут касаться оформления PR. Другие — проверять смежные условия, которые составляют основу процесса принятия изменений.
Если рутинные проверки не автоматизированы, человек может начать их забывать или обходить. Потому, что рутина — это скучно.

Visual Studio Team Services предлагает довольно удобную инфраструктуру для обработки Pull Request. Сюда входят настраиваемые политики merge builds, назначение ревьюеров, правила слияния принимаемых изменений. Все это дополненной удобной системой обсуждения и комментирования кода.

Мощнейшим инструментом расширения процесса Pull Request являются внешние подключаемые политики.

Об их создании и использовании и поговорим (и посмотрим код)

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

Пора было переходить от слов к делу — менять процессы.

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

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

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

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

Решение любой из указанных задач будет положительно влиять на скорость обработки заявок.

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

В нашем случае задачу можно сформулировать следующими задачами классификации:

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

• применимость процесса — когда имеет смысл его внедрять
• основные этапы процесса, активности, вовлеченные ресурсы и результаты
• планирование релизов: календарь, объем, параллельное выполнение
• некоторые проблемы доставки в релизах

Проблема