Зацепило про 1 млн строк, сразу хочется спросить: А если он принесёт просто на порядок больше записей? Кажется, что база стоит за приложением и бы проверял на нт только реальные сценарии на реальной системе и железе
Кажется дзен TDD так и не понят, что тесты пишутся до кода и как это будет проверяться проектируется одновременно с системой.
Вот честно, проще тесту скормить кусок непонятных данных отброшенных в лог, чем страдать ловя их в потоке.
И это хорошо когда данные просто поменялись, а когда начинается подмес чего-то нового? А потом ещё и ещё? Вам же нужно стабильно обрабатывать и первое и второе и третье. Без тестов тут такой замес можно устроить...
И ещё раз - пишите тесты до кода и на все уровни сразу. Хотя-бы их канву...
Какое время вы отводить на обновление рычага? Зачем ещё одна точка отказа всего, если ределой занимает секунды и обновит конфигурацию именно там где нужно?
Ну и по существу - где воздействия, принятие решений, стимулирование? Все то что писали несколько лет назад рекламируя системы геймификации? В чем тут гипер, если это просто база и набор графиков, без глубоких интеграций?
Насколько я помню водопад умер под тяжестью главы по управлению рисками. Всё признали что заморозить мир на 2-3 года нельзя, а бороться - дорого.
Дальше вернулись к v-модели и итеративной разработке. Где один виток - это водопад, а точнее v-модель с четкими dod, и прочими критериями результата. Размер витка такой, чтоб бороться с рисками (включая риски изменений) было ещё приемлемо.
Итого получили размер витка от 1 недели до 1-3 месяцев в зависимости от бизнеса.
При этом на отрезке 1-4 недели на риски можно почти забить, а вот на 3 месяцах на них придётся потратиться. Поэтому в этой части аджайл пророс как более дешёвый.
А ещё agile предложил подстраиваться процессы под людей, а не людей под процессы и другие ценности, внедрения которых не случилось много где, но почему-то это все называют это agile, а не "скрам но".
Если количество регистраций столь велико, что это нужно учитывать, то вам нужно сохранять желаемый username здесь же, потому что иначе вы будете объяснять пользователю что груздь. А ещё должны вернуть возможные варианты для его выбора, т.к. при значимости нагрузки от такой операции шансов придумать username самостоятельно почти нет.
А констреинт это (кеш в базе) или данные холодные или это какой-то самопальный хеш уже сильно второстепенно при таких просчетах.
При такой нагрузке, скорее всего это будет вообще какое-то api какого-нибудь sso
В робот подключается все что выше бесплатного нативным образом и ещё вагончик. Причём обёртка дают неплохой уровень тулинга и абстракции. Настолько не плохой, что нативно их использовать уже не захочется.
А для нт там своя жизнь. Зря вы его вообще здесь упоминаете.
Используйте yml вместо json - его существенно удобнее diffить в pr
Выделяем общий код тестов хорошо ложится на идеологию кейвордов. Все тоже самое, но выделяемый код имеет понятную ценность и само дерево кейвордов можно проработать заранее, а не хаотично
Очень важный пункт - помните про параллельность и уборку за собой не озвучен.
Выбор данных, их подготовка, приборка не должны влиять на систему радикальным образом. Например, видел историю когда статистика в базе сходила с ума от запуска тестов и тестовая зона вела себя не адекватно
Хорошо сказали про api. Но нужно добавить, что не следует бояться расширять апи в целях увеличения тестируемости продукта. Это лучше прямых конектов в приложение.
Только думаем о количестве секретов и потоков. Например интеграцонные тесты получающие 200 паролей на старте и работающие в независимых 80 потоков убивают вольт. 200*80 это до 16ktps если не тормозить запуск.
Тоже, но в ленивом обращении может давать 1кк обращений в час, от чего вольту тоже станет грустно.
Зачастую проблемы всем известны. А вот решения - нет. А если и известны, то на них нет денег. А если есть, то результат оказывается что лучше засекретить.
Часто хочется увидеть скорее наборы решений, их метрики, какие решения оказались проблемными и как это решать. Зачастую это требует совсем другого уровня от специалистов (не только ИБ), а этого нет.
При выборе и демонстрации такого метода логирования важно было бы сказать:
Не забудь спрятать чувствительную информацию, в частности пароли
Обратите внимание на объем сообщений и их частоту. Вполне реально упереться в лимиты транспорта
Включите бьютефаер трейсов и используйте форматирование сообщений, ведь такой лог для человека, а не последующей Обработки
Ну и напоследок - обработайте недоступность транспорта логов. Падать от невозможности залогироваться больно. Возможно у вас более 1 транспорта или можно настроить ещё один для последнего мяу.
Меня смущает тут панда - там же под капотом либа для чтения. По идее нужно её проверять.
Зацепило про 1 млн строк, сразу хочется спросить: А если он принесёт просто на порядок больше записей? Кажется, что база стоит за приложением и бы проверял на нт только реальные сценарии на реальной системе и железе
Кажется дзен TDD так и не понят, что тесты пишутся до кода и как это будет проверяться проектируется одновременно с системой.
Вот честно, проще тесту скормить кусок непонятных данных отброшенных в лог, чем страдать ловя их в потоке.
И это хорошо когда данные просто поменялись, а когда начинается подмес чего-то нового? А потом ещё и ещё? Вам же нужно стабильно обрабатывать и первое и второе и третье. Без тестов тут такой замес можно устроить...
И ещё раз - пишите тесты до кода и на все уровни сразу. Хотя-бы их канву...
Как быть с изоляцией теста и прода?
Какое время вы отводить на обновление рычага? Зачем ещё одна точка отказа всего, если ределой занимает секунды и обновит конфигурацию именно там где нужно?
Ну и по существу - где воздействия, принятие решений, стимулирование? Все то что писали несколько лет назад рекламируя системы геймификации? В чем тут гипер, если это просто база и набор графиков, без глубоких интеграций?
И рядом статья о неадекватности результата
Хотел отправить ребёнку прочитать, но кроме набора терминов один только мусор
Очнь странное сравнение.
Насколько я помню водопад умер под тяжестью главы по управлению рисками. Всё признали что заморозить мир на 2-3 года нельзя, а бороться - дорого.
Дальше вернулись к v-модели и итеративной разработке. Где один виток - это водопад, а точнее v-модель с четкими dod, и прочими критериями результата. Размер витка такой, чтоб бороться с рисками (включая риски изменений) было ещё приемлемо.
Итого получили размер витка от 1 недели до 1-3 месяцев в зависимости от бизнеса.
При этом на отрезке 1-4 недели на риски можно почти забить, а вот на 3 месяцах на них придётся потратиться. Поэтому в этой части аджайл пророс как более дешёвый.
А ещё agile предложил подстраиваться процессы под людей, а не людей под процессы и другие ценности, внедрения которых не случилось много где, но почему-то это все называют это agile, а не "скрам но".
Если количество регистраций столь велико, что это нужно учитывать, то вам нужно сохранять желаемый username здесь же, потому что иначе вы будете объяснять пользователю что груздь. А ещё должны вернуть возможные варианты для его выбора, т.к. при значимости нагрузки от такой операции шансов придумать username самостоятельно почти нет.
А констреинт это (кеш в базе) или данные холодные или это какой-то самопальный хеш уже сильно второстепенно при таких просчетах.
При такой нагрузке, скорее всего это будет вообще какое-то api какого-нибудь sso
Видно посиделок с родней где пересекаются 3 юродные тёти и 5 юродные внучатые племянники не было у вас.
Ещё интересно собрать мед.диагнозы. Хотя-бы основные.
А Nord от Nexign смотрели?
В робот подключается все что выше бесплатного нативным образом и ещё вагончик. Причём обёртка дают неплохой уровень тулинга и абстракции. Настолько не плохой, что нативно их использовать уже не захочется.
А для нт там своя жизнь. Зря вы его вообще здесь упоминаете.
Что сразу бросилось в глаза:
Используйте yml вместо json - его существенно удобнее diffить в pr
Выделяем общий код тестов хорошо ложится на идеологию кейвордов. Все тоже самое, но выделяемый код имеет понятную ценность и само дерево кейвордов можно проработать заранее, а не хаотично
Очень важный пункт - помните про параллельность и уборку за собой не озвучен.
Выбор данных, их подготовка, приборка не должны влиять на систему радикальным образом. Например, видел историю когда статистика в базе сходила с ума от запуска тестов и тестовая зона вела себя не адекватно
Хорошо сказали про api. Но нужно добавить, что не следует бояться расширять апи в целях увеличения тестируемости продукта. Это лучше прямых конектов в приложение.
Только думаем о количестве секретов и потоков. Например интеграцонные тесты получающие 200 паролей на старте и работающие в независимых 80 потоков убивают вольт. 200*80 это до 16ktps если не тормозить запуск.
Тоже, но в ленивом обращении может давать 1кк обращений в час, от чего вольту тоже станет грустно.
А кто что использует для календаря дежурств? Чтоб действительно удобно было.
Все зависит от целей и набираемого коллектива. Например может быть и 1:7 и 1:1000. Первый случай - коллектив фриков нанявший себе в команду мамочку.
Зачастую проблемы всем известны. А вот решения - нет. А если и известны, то на них нет денег. А если есть, то результат оказывается что лучше засекретить.
Часто хочется увидеть скорее наборы решений, их метрики, какие решения оказались проблемными и как это решать. Зачастую это требует совсем другого уровня от специалистов (не только ИБ), а этого нет.
При выборе и демонстрации такого метода логирования важно было бы сказать:
Не забудь спрятать чувствительную информацию, в частности пароли
Обратите внимание на объем сообщений и их частоту. Вполне реально упереться в лимиты транспорта
Включите бьютефаер трейсов и используйте форматирование сообщений, ведь такой лог для человека, а не последующей Обработки
Ну и напоследок - обработайте недоступность транспорта логов. Падать от невозможности залогироваться больно. Возможно у вас более 1 транспорта или можно настроить ещё один для последнего мяу.
Мне одного смущает, что лаконичные и понятные фразы превращаются в портянку тяжело читаемого текста?
А https://robotframework.org/ живёт и развивается. Не хотите перейти на него?