@ShIV03 Про формулировку — согласен, плохая. «Без обязательств» это слово из моей головы, а не из головы того, кто спрашивает. Человек ничего не отказывается на себя брать, он просто ещё не понял, что ему предлагают. Фраза выдаёт взгляд «посетитель = недозаявка».
Переписал не фразу, а всё вступление: там была продажная рамка про созвоны и формы, которой в технической статье вообще нечего делать. Спасибо, что ткнули.
При этом сделал я, кажется, ровно то, к чему ваша история и ведёт. Не понял — значит надо показать, а не рассказывать.
А разрыв между концепцией и реализацией — самая близкая мне часть. Презентацией он не закрывается, просто всплывает позже и болезненнее. Поэтому на стенде висят девять пустых панелей, которые я не стал заполнять синтетикой: у клиента на виртуалке они будут пустыми точно так же, и пусть это будет видно сразу, а не через две недели. И поэтому «данные синтетические» написано рядом с графиками, а не мелким шрифтом внизу.
Ваш «переводчик» — хороший тест, кстати. Если демо нужен переводчик, это ещё не демо.
Справедливо, но с двумя поправками к схеме. Первая: чёрный список заменить белым. Инвентарь стенда закрытый и известный — srv-*, 10.20.30.0/24, четыре вымышленных домена. Значит правило не «не должно встречаться запрещённое», а «всё, что похоже на имя хоста, адрес или домен, обязано быть из списка, иначе падаем». Ваш BANK-PROD-1 чёрный список поймает только если я его заранее угадал; белый поймает и тот, который я не предвидел.
Вторая: заголовков и описаний мало. Реальное имя с большей вероятностью приедет не из JSON дашборда, а из самих данных — значением метки в ответе /panels/<id>/query. Прогонять надо и ответы тоже.
И запускать не только при сборке. Тенант может испортиться потом — достаточно, чтобы кто-то направил агент в демо-аккаунт. Поэтому отдельной периодической проверкой, и при срабатывании снимать публикацию, а не писать warning в лог.
Спасибо, отличный пример — и нет, ни в одну из трёх осей он не попадает. Все три описывают то, что приходит снаружи: объём, кардинальность и поведение клиента при отказе. Ваш случай — четвёртая ось: нагрузка, которую система создаёт сама себе, и она от трафика не зависит вообще.
У меня из той же категории два эпизода. Ретрай-шторм из статьи: 61 417 запросов от собственных агентов, снаружи при этом ни одного пользователя. И 4702 рестарта хранилища логов по memcg-OOM, копившиеся месяцами при почти нулевой нагрузке — их не поймал бы никакой нагрузочный сценарий, потому что ловить надо было не пик, а фон.
Практический вывод, который допишу в чек-лист после вашего комментария: тест с нулевой нагрузкой. Оставить стенд на сутки совсем без трафика и посмотреть дельту диска, число рестартов и рост системных таблиц. Ваши 12 ГБ на 543 КБ полезных данных ловятся ровно так.
Разбор пойду читать. TRUNCATE за минуту вместо часа профилирования — хороший приём.
Справедливо. Контуры-то разделены — тест и прод это разные серверы. Пересеклось другое: тестовая машина работала ещё и как обычный клиент прода, агенты с неё писали в боевую платформу. Мне это было нужно как постоянный живой поток и способ ловить деградацию раньше, чем её заметит клиент.
Information
Rating
579-th
Location
Москва и Московская обл., Россия
Date of birth
Registered
Activity
Specialization
Технический директор, Инженер по доступности сервисов
@ShIV03 Про формулировку — согласен, плохая. «Без обязательств» это слово из моей головы, а не из головы того, кто спрашивает. Человек ничего не отказывается на себя брать, он просто ещё не понял, что ему предлагают. Фраза выдаёт взгляд «посетитель = недозаявка».
Переписал не фразу, а всё вступление: там была продажная рамка про созвоны и формы, которой в технической статье вообще нечего делать. Спасибо, что ткнули.
При этом сделал я, кажется, ровно то, к чему ваша история и ведёт. Не понял — значит надо показать, а не рассказывать.
А разрыв между концепцией и реализацией — самая близкая мне часть. Презентацией он не закрывается, просто всплывает позже и болезненнее. Поэтому на стенде висят девять пустых панелей, которые я не стал заполнять синтетикой: у клиента на виртуалке они будут пустыми точно так же, и пусть это будет видно сразу, а не через две недели. И поэтому «данные синтетические» написано рядом с графиками, а не мелким шрифтом внизу.
Ваш «переводчик» — хороший тест, кстати. Если демо нужен переводчик, это ещё не демо.
добавил разделом в статью, белый список вместо чёрного, проверяю и ответы
/panels/<id>/queryСправедливо, но с двумя поправками к схеме. Первая: чёрный список заменить белым. Инвентарь стенда закрытый и известный —
srv-*, 10.20.30.0/24, четыре вымышленных домена. Значит правило не «не должно встречаться запрещённое», а «всё, что похоже на имя хоста, адрес или домен, обязано быть из списка, иначе падаем». ВашBANK-PROD-1чёрный список поймает только если я его заранее угадал; белый поймает и тот, который я не предвидел.Вторая: заголовков и описаний мало. Реальное имя с большей вероятностью приедет не из JSON дашборда, а из самих данных — значением метки в ответе
/panels/<id>/query. Прогонять надо и ответы тоже.И запускать не только при сборке. Тенант может испортиться потом — достаточно, чтобы кто-то направил агент в демо-аккаунт. Поэтому отдельной периодической проверкой, и при срабатывании снимать публикацию, а не писать warning в лог.
Спасибо, отличный пример — и нет, ни в одну из трёх осей он не попадает. Все три описывают то, что приходит снаружи: объём, кардинальность и поведение клиента при отказе. Ваш случай — четвёртая ось: нагрузка, которую система создаёт сама себе, и она от трафика не зависит вообще.
У меня из той же категории два эпизода. Ретрай-шторм из статьи: 61 417 запросов от собственных агентов, снаружи при этом ни одного пользователя. И 4702 рестарта хранилища логов по memcg-OOM, копившиеся месяцами при почти нулевой нагрузке — их не поймал бы никакой нагрузочный сценарий, потому что ловить надо было не пик, а фон.
Практический вывод, который допишу в чек-лист после вашего комментария: тест с нулевой нагрузкой. Оставить стенд на сутки совсем без трафика и посмотреть дельту диска, число рестартов и рост системных таблиц. Ваши 12 ГБ на 543 КБ полезных данных ловятся ровно так.
Разбор пойду читать. TRUNCATE за минуту вместо часа профилирования — хороший приём.
Справедливо. Контуры-то разделены — тест и прод это разные серверы. Пересеклось другое: тестовая машина работала ещё и как обычный клиент прода, агенты с неё писали в боевую платформу. Мне это было нужно как постоянный живой поток и способ ловить деградацию раньше, чем её заметит клиент.