AHS疫苗新冠预约秒崩

GetNewJob · Feb 24th, 2021, 10:25

AHS今天上午8点开始新冠疫苗预约，10秒后网站就不能进了，811电话也无法接通，可谓秒崩。这么长时间了，根本没做好准备，对这些官僚机构太失望了。

陆仁嘉 · Feb 26th, 2021, 15:30

引用:

作者: GetNewJob

AHS今天上午8点开始新冠疫苗预约，10秒后网站就不能进了，811电话也无法接通，可谓秒崩。这么长时间了，根本没做好准备，对这些官僚机构太失望了。

秒崩不秒崩都是钱说话。把淘宝双十一的计算能力买下来倒是不会秒崩了，你愿意多掏税钱吗？

就算不秒崩，一天也只有一万多不到两万剂疫苗，你进去也是预约一个星期以后的。两三天以后再登录，也是预约一个星期以后。

jo jo · Feb 26th, 2021, 15:46

你们都75了？！？

GetNewJob · Feb 26th, 2021, 18:14

就不能给家里老人约吗？

引用:

作者: jo jo

你们都75了？！？

GetNewJob · Feb 26th, 2021, 18:17

还真不是钱的问题，是程序有BUG，下午6点多改弄好了。这就是拿了税钱不好好干活，掏3倍税钱还会这样，应该公私双轨制。

引用:

作者: 陆仁嘉

秒崩不秒崩都是钱说话。把淘宝双十一的计算能力买下来倒是不会秒崩了，你愿意多掏税钱吗？

就算不秒崩，一天也只有一万多不到两万剂疫苗，你进去也是预约一个星期以后的。两三天以后再登录，也是预约一个星期以后。

jo jo · Feb 26th, 2021, 18:27

没经验，，，不好意思

China_Soul · Feb 26th, 2021, 19:04

引用:

作者: GetNewJob

还真不是钱的问题，是程序有BUG，下午6点多改弄好了。这就是拿了税钱不好好干活，掏3倍税钱还会这样，应该公私双轨制。

说的好像洞悉了政府网站的技术细节似的，其实只是6点的时候没那么多人登录罢了

jo jo · Feb 26th, 2021, 19:07

没用fastly服务肯定

GetNewJob · Feb 26th, 2021, 21:21

你们看来真不关心本地新闻，是艾蒙顿的三兄弟提出了BUG，同时卡大的一个教授给AHS支招，改好了BUG后，又外挂了一个丹麦的什么程序（3万刀），20分钟就解决了。

这是新闻里都有的。

https://www.cbc.ca/news/canada/calga...able-1.5927602

引用:

作者: China_Soul

说的好像洞悉了政府网站的技术细节似的，其实只是6点的时候没那么多人登录罢了

jo jo · Feb 26th, 2021, 23:43

overwhelmed 正经说来不算是bug

看了看三兄弟的tweet，他们的解决办法只是bypass了最近地址匹配那个最冗长的一步，
可以跳过一步继续倒的确是个security bug

但之前系统崩溃最大原因是没有处理好负载平衡
咱家的fastly比queue-it 性能好多了还便宜怎么不用呢？？
https://www.g2.com/compare/fastly-vs-queue-it

HXS1966 · Feb 27th, 2021, 12:07

引用:

作者: jo jo

overwhelmed 正经说来不算是bug

看了看三兄弟的tweet，他们的解决办法只是bypass了最近地址匹配那个最冗长的一步，
可以跳过一步继续倒的确是个security bug

但之前系统崩溃最大原因是没有处理好负载平衡
咱家的fastly比queue-it 性能好多了还便宜怎...

地址匹配是个预约的很正常的程序，不是什么Bug,跳过也可以用也算不上安全漏洞，是降级使用。现在临时去掉了最近地址匹配程序，虽然可以加快在线预约，但是结果是使许多人要跨区域。
Geocoding计算当然是许多应用的优化预先选项，缺陷是需要大量的计算能力来保障；突然的访问量增加使计算服务器垮掉，太正常。牺牲掉地址匹配来运转是降级使用。
空间计算许多应用目前不能实际使用，就是计算机能力限制问题。那个用照片就骗过手机人脸识别开机的问题，是空间识别模式过于简化（简化后才得以能用），是手机计算能力不能适用于复杂的识别计算比对。

jo jo · Feb 27th, 2021, 12:53

emm，能skip workflow的，很bug了啊，基本就是用一个session ID维护session一致性，
这么shi的安全设计，幸好那三兄弟不是坏人，只用这个破绽跳转加速预定，要有别的用心的，解析session ID再插入些其他script做点奇奇怪怪的事儿，怎么防咧？？

运算能力不足，可以用负载平衡排队，而地址匹配，尤其有邮编情况下，加上时间充其量就是个二维匹配计算，算法能复杂到什么程度啊？
Alberta才多少老人和多少clinics，一个booking 程序承载不起，是有点奇葩的。这个不能甩锅运算能力的说
系统崩溃不是程序bug，是程序defect
bug是加exception handler就能解决的；defect是设计问题，得重新整理整理

jo jo · Feb 27th, 2021, 13:17

例如一个简单的瘫痪攻击，感觉能行：解析了session后，做多个机器人，同一个页面，循环申请地址匹配，这样那个地址服务guji能很忙，因为queue-it只负责session分配排队，session内的server负载还得自己整
大意就是我打不上你们也甭想打得了！？

HXS1966 · Feb 27th, 2021, 18:03

如果仅仅是依据邮编进行最近打疫苗地址匹配，也可以不进行实时实质空间最近距离计算匹配，可以在有效打疫苗地址的表格数据中加一个包括的邮编Field，预先植入地址匹配表格数据，这样一来用户输入邮编后就不用进行空间距离计算匹配了，只进行表格数据简单比对就可以。
估计AHS的疫苗预约计划制定时候，没人注意到原来的实质空间计算带来的服务器计算问题，没有预先在打疫苗有效地点表格中预植邮编数据。

空间计算背景是要把整个卡城变为格栅数据，再根据输入者给的邮编定位点，进行空间Spatial Join分析，算出最近的疫苗点，再预约排队。空间计算当然是很占Ram的，如果单位格栅定为2m*2m,卡城850平方公里范围，格栅点数量是巨大的，虽然空间Spatial Join分析相对快速，但是相对Table Query来说是海量的分析量增加。

用GIS空间分析功能，很难预测一个分析完成需要的时间，监测服务器崩溃值是不容易的。

jo jo · Feb 27th, 2021, 18:56

你想太多了，如果计算几个两点距离再排优都做不到，那是多糟糕的性能啊
而且现在stress test的工具那么多，，，有啥不容易哒。。。

不过，一个省就这么点儿老人流量，再过三五个星期，疫苗到位，药店服务点可以现场排队时，请人来预约都没有了；这么短期的应用，的确不值得花费太多预算做周全。

你看看queue-it的功能，9是简单粗暴的，只是在系统接入前加了个等待排队界面，没有增加系统负载capacity，也没有加真正服务访问的负载平衡，只是让你等得好看点，没那么容易生气。

Feb 24th, 2021, 10:25	#1
GetNewJob Senior Member 注册日期: Apr 2006 帖子: 838	AHS疫苗新冠预约秒崩 AHS今天上午8点开始新冠疫苗预约，10秒后网站就不能进了，811电话也无法接通，可谓秒崩。这么长时间了，根本没做好准备，对这些官僚机构太失望了。
GetNewJob Senior Member 注册日期: Apr 2006 帖子: 838

Feb 26th, 2021, 15:46	只看该作者 #3
jo jo 转啊转啊转注册日期: Jul 2007 帖子: 34,092 积分:5 精华:2 声望: 24936019	你们都75了？！？

Feb 26th, 2021, 18:27	只看该作者 #6
jo jo 转啊转啊转注册日期: Jul 2007 帖子: 34,092 积分:5 精华:2 声望: 24936019	没经验，，，不好意思

Feb 26th, 2021, 19:07	只看该作者 #8
jo jo 转啊转啊转注册日期: Jul 2007 帖子: 34,092 积分:5 精华:2 声望: 24936019	没用fastly服务肯定

Feb 26th, 2021, 23:43	只看该作者 #10
jo jo 转啊转啊转注册日期: Jul 2007 帖子: 34,092 积分:5 精华:2 声望: 24936019	overwhelmed 正经说来不算是bug 看了看三兄弟的tweet，他们的解决办法只是bypass了最近地址匹配那个最冗长的一步，可以跳过一步继续倒的确是个security bug 但之前系统崩溃最大原因是没有处理好负载平衡咱家的fastly比queue-it 性能好多了还便宜怎么不用呢？？ https://www.g2.com/compare/fastly-vs-queue-it

Feb 27th, 2021, 12:53	只看该作者 #12
jo jo 转啊转啊转注册日期: Jul 2007 帖子: 34,092 积分:5 精华:2 声望: 24936019	emm，能skip workflow的，很bug了啊，基本就是用一个session ID维护session一致性，这么shi的安全设计，幸好那三兄弟不是坏人，只用这个破绽跳转加速预定，要有别的用心的，解析session ID再插入些其他script做点奇奇怪怪的事儿，怎么防咧？？运算能力不足，可以用负载平衡排队，而地址匹配，尤其有邮编情况下，加上时间充其量就是个二维匹配计算，算法能复杂到什么程度啊？ Alberta才多少老人和多少clinics，一个booking 程序承载不起，是有点奇葩的。这个不能甩锅运算能力的说系统崩溃不是程序bug，是程序defect bug是加exception handler就能解决的；defect是设计问题，得重新整理整理

Feb 27th, 2021, 13:17	只看该作者 #13
jo jo 转啊转啊转注册日期: Jul 2007 帖子: 34,092 积分:5 精华:2 声望: 24936019	例如一个简单的瘫痪攻击，感觉能行：解析了session后，做多个机器人，同一个页面，循环申请地址匹配，这样那个地址服务guji能很忙，因为queue-it只负责session分配排队，session内的server负载还得自己整大意就是我打不上你们也甭想打得了！？

Feb 27th, 2021, 18:03	只看该作者 #14
HXS1966 Senior Member 注册日期: Jun 2006 帖子: 4,515 声望: 1177764	如果仅仅是依据邮编进行最近打疫苗地址匹配，也可以不进行实时实质空间最近距离计算匹配，可以在有效打疫苗地址的表格数据中加一个包括的邮编Field，预先植入地址匹配表格数据，这样一来用户输入邮编后就不用进行空间距离计算匹配了，只进行表格数据简单比对就可以。估计AHS的疫苗预约计划制定时候，没人注意到原来的实质空间计算带来的服务器计算问题，没有预先在打疫苗有效地点表格中预植邮编数据。空间计算背景是要把整个卡城变为格栅数据，再根据输入者给的邮编定位点，进行空间Spatial Join分析，算出最近的疫苗点，再预约排队。空间计算当然是很占Ram的，如果单位格栅定为2m*2m,卡城850平方公里范围，格栅点数量是巨大的，虽然空间Spatial Join分析相对快速，但是相对Table Query来说是海量的分析量增加。用GIS空间分析功能，很难预测一个分析完成需要的时间，监测服务器崩溃值是不容易的。

Feb 27th, 2021, 18:56	只看该作者 #15
jo jo 转啊转啊转注册日期: Jul 2007 帖子: 34,092 积分:5 精华:2 声望: 24936019	你想太多了，如果计算几个两点距离再排优都做不到，那是多糟糕的性能啊而且现在stress test的工具那么多，，，有啥不容易哒。。。不过，一个省就这么点儿老人流量，再过三五个星期，疫苗到位，药店服务点可以现场排队时，请人来预约都没有了；这么短期的应用，的确不值得花费太多预算做周全。你看看queue-it的功能，9是简单粗暴的，只是在系统接入前加了个等待排队界面，没有增加系统负载capacity，也没有加真正服务访问的负载平衡，只是让你等得好看点，没那么容易生气。