Как стать автором
Обновить

Комментарии 9

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

И ещё. Почему ЕСИА, которое должно быть готово к синхронной подаче заявлений в Москве и Питере, оказалось не готово к нагрузке в Хабаровске. У вас больший уровень использования госуслуг?

По ЕСИА я не могу сказать почему и даже не могу утверждать, что это было так. Это было в 2019 г. В субботу утром — моя гипотеза, что технические работы проводились. Это ночь по Москве — с этим во многих российских сервисах приходится сталкиваться. Кроме того, на мой взгляд — там разные группы серверов для разных макрорегионов. Но тех.ответ — все работает штатно. Кроме того, вылазают и сетевые проблемы периодически, какие-то операторы весть трафик кешируют, что-то не выдерживает. И ещё часто сбоят не сами системы, а системы защиты этих систем. В этом году такой проблемы не было — но услуга подаваль в пятницу вечером по Москве (у нас ночью).


По растягиванию — всё просто. Форма очень простая получилась и фактически полностью заполненная сразу, особенно если черновик предварительно заполнить. Поэтому черновик убрали. И убрали автоподстановку информации о детях и документах в этой услуге. Вбиваение этих данных требует времени. У обычного пользователя на это уходит от минуты (копировать/вставить и перечитать), у того кто вбивает на компьютере руками до 2-4х минут, а с телефонов и того больше.


Но более правильный вариант — форму вообще не показывать до начала подачи, иначе можно сгенерировать скрипты и заполнить всё за 1 секунду или вообще post запрос подготовить. А т.к. спрос есть — это может породить рынок.

А почему бы не создать очередь отправки в браузерах? То есть в момент отправки запроса фиксируется ид, а сама отправка в СУБД идет позднее (и отображается кручением часов).

Ну и на самый главный вопрос нет ответа — если Хабаровск создает значимую нагрузку, то что же в Москве? Или как сейчас — синхронная нагрузка по всей России?

Можно по всякому решать. Единственно в услуге запись в первый класс очень критично время подачи — по нему формируется очередь — это юридически значимо — а передать id без минимум ФИО родителя/ребенка — это уже не то, вдруг потом данные не дойдут.


Тем более проблемы на этапе подачи не было — нагрузка растянутая на 3-5 минут уже вполне решаемая на этих объемах. И её протестировать хорошо вполне возможно. Основаня проблема в обновлении в 0:00 минут — этот пик, дельта фукцию, не обойти никак. И её кстати сложно сэмулировать нагрузкой — можно только экстраполяции делать на динамике с разной нагрузкой и выдвигать гипотезы — что вперед будет "выбрано" — канал, производительность коммутационного оборудования, производительность защиты или ошибки в настройках алогоритмов, ресурсы сервера. Кстати канал и коммутаторы не всегда в ЦОДе — ведь есть ещё операторы связи в городах, районах и у некоторых они не с таким уж большим резервом — а трафик из ютуба очень отличается от этой δ-функции.


Про ЕСИА ничего вам не могу допонительно сказать. Не думаю, что Хабаровск создает значимую нагрузку, даже с остальными регионами ДВ — меньше 7ми миллионов на 3 часовых пояса. Но факторы складываются по разному, а внешняя система — есть внешняя система.

Мне кажется, что время подачи критично не для всех для малого числа школ. Соответственно можно подачу в эти школы делать сразу, а в иные — с задержкой на случайное число секунд.

Так именно родители этого малого числа школ и создают эту нагрузку — их примерно до 10% от общего кол-ва школьников. В остальные школы проще прийти с документами до конца мая без шума и спешки.

Ну так простая задержка для оставшихся 90% уменьшит трафик в 10 раз.

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


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


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


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


Досылка даных — это уже другой процесс. Такой например есть в госэкспертизе. Там вы подаете заявление, но реальные данные выгружаете (сканы документов проектых) уже после регистрации факта подачи.


Хотя де юре можно сделать простую кнопку — "встать очередь" — так видят услугу многие пользователи и к этому логика развития эл.услуг идет. Только нужно адм.регламенты написать и закрепить их. Тогда нужно передать только сессию пользователя и его "желание получить услугу". А данные дослать или запросить в других ведомствах. Но тогда мы опять же получим δ-функцию в отправке.


И получим кучу других проблем — а действительно он выразил это желание или случайно нажал? Это как в договоре — банку недостаточно вашей подписи, они ещё и ФИО просит написать — чтобы гарантировать, что это вы. А нотариус сколько вопросов задает, чтобы понять дееспособность и осознанность намерения. Ввод доп.данных служит в том числе и этой цели. Ну и растягивает подачу на какое-то время, меняя модель случайно успел нажать, систему случано раньше получила из-за случайных сетевого состояния — на какой-то соревнуемый навык — быстрее печатал, знал как скрипт написать автозаполнения — это вместо быстрого коня на диком западе ))) Иначе можно и просто лотерею ввести. Что будет справедливее?

Боюсь, что вы не поняли, что я предлагаю. Есть смысл приоритетно отправлять запросы по школам, где конкуренция есть. Так, чтобы они точно не были отброшены из-за слишком большого трафика. Запросы по остальным школам могут подождать пару минут перед отправкой. А выделить приоритетные школы можно на клиенте.

Что касается социальной справедливости — она достигается совсем иными мерами. Надо проводить обследование и раз в год менять количество классов и границы закрепленных участков. Главный принцип — первоклассник не должен переходить на пути в школу дороги с оживлённым движением.

Там есть один секрет — в детском саду и началке очень важна личность учителя (воспитателя). И почти не важно само учреждение. Если у ребёнка с учителем нет контакта — он не будет учиться. Если контакт есть — при самом неумелом учителе ребенок выучится.

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

Публикации

Истории