Тема как они из текстовых логов достают нужные данные не раскрыта. Structured log это хорошо, но где-то ведь должна быть и пост-обработка логов (кто-то должен посчитать время между log-event start и log-event end)
Тем что штатно такое заббикс не умеет и надо костылить в каждом хосте. А это значит все шаблонные триггеры надо привязывать к проверке на доступность прокси.
Смотрим, как должно быть по ТЗ. Сравниваем с тем, как модуль сделан в реальности. Но главное — учимся смотреть на продукт и изменения с точки зрения здравого смысла и обычного пользователя.
Удобен ли рабочий сценарий? Всё сделано «по-человечески»? Параллельно проводим ещё и usability-тестирование.
Разве это не задача Feature Owner/Product Owner/Analytic описывать сценарии по человечески, до того как они попадут к разработчикам? Не он ли должен описывать совместно с QA что и как тестировать?
Почему у вас QA определяют то как выглядит продукт?
1) чтобы использовать Sentry нужно вносить изменения в код
PM > Install-Package NLog.Zidium
А это по вашему что?
3) в Sentry нет метрик
Такой-то экспешен выпал 99 раз. Пардон, но наличие сообщений в Sentry уже само по себе метрика.
4) в Sentry нет логов
У вас будет стектрейс со всеми значениями переменных + у вас есть доступ к коду. Если вы по этим компонентам не можете реконструировать что произошло, то чем вам помогут логи?
Покажите пожалуйста хоть одну EULA где про это написано? Везде пишут "сервис предоставляется как есть, без каких либо гарантий. Все риски и ущерб от использования сервисом принимает на себя пользователь".
Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.
И вот тут есть проблема — приложение должно особым образом обрабатывать выход (закрытие вкладки или окна). Так же стоит обратить внимание что токен не может быть отозван серверном до истечения expire. Ну то есть можно, но вообще нет.
А как вы проверяете что легальное приложение не обменивается данными (или не имеет тех же счетчиков) с VK?
На Курской найти поесть наверно не самая большая проблема в отличии от спальных районов...
Хардкорный траблшутинг — всё как мы любим. Спасибо!
Либо кто-то по глупости купил либо кто-то удачно избавился от балласта
Тема как они из текстовых логов достают нужные данные не раскрыта. Structured log это хорошо, но где-то ведь должна быть и пост-обработка логов (кто-то должен посчитать время между log-event start и log-event end)
Тем что штатно такое заббикс не умеет и надо костылить в каждом хосте. А это значит все шаблонные триггеры надо привязывать к проверке на доступность прокси.
В общем такое себе удовольствие.
Расскажите как вы ревьюите код при невозможности указать больше одного ревьюера.
Вот в этом релизе появилась фишка (которая например есть в Фабрикаторе) — Code owners, как без нее назначать на ревью людей из команды CI/Devops?
Дело Mithgol живёт...
Тема "Development" нераскрыта, как-то больше про Research и менеджмент.
Разве это не задача Feature Owner/Product Owner/Analytic описывать сценарии по человечески, до того как они попадут к разработчикам? Не он ли должен описывать совместно с QA что и как тестировать?
Почему у вас QA определяют то как выглядит продукт?
А это по вашему что?
Такой-то экспешен выпал 99 раз. Пардон, но наличие сообщений в Sentry уже само по себе метрика.
У вас будет стектрейс со всеми значениями переменных + у вас есть доступ к коду. Если вы по этим компонентам не можете реконструировать что произошло, то чем вам помогут логи?
Покажите пожалуйста хоть одну EULA где про это написано? Везде пишут "сервис предоставляется как есть, без каких либо гарантий. Все риски и ущерб от использования сервисом принимает на себя пользователь".
Только не 4, а 3 надо брать. В 3 Cell, в 4 AMD и не факт что на нем нет уязвимости.
Мне приходит на ум только один аргумент — сложности с дистрибуцией.
Если для питоновских либ все более менее стандартно, то где хранить dll и кто и как будет определять какую либу надо libmagic.so libmagic.dll
И вот тут есть проблема — приложение должно особым образом обрабатывать выход (закрытие вкладки или окна). Так же стоит обратить внимание что токен не может быть отозван серверном до истечения expire. Ну то есть можно, но вообще нет.