最近，博客园在技术升级上做了积极向上的努力，虽然中间过程出现反复，但姑且先不论最终升级后客户体验方面的提升，在升级过程中探索排查问题和解决问题的过程，本身就能帮助博客园团队和广大用户积累经验和提升能力，这种实践机会是千金难买的。
阅读了博客园官方的相关文章，其中充满对广大用户浓浓的善意，这从多数同样充满关心的回复里能得到充分体现。其实，博客园团队在本次乃至之后的升级过程中，不妨做得更自信些，毕竟博客园的技术实力和品牌摆在这里。
1 以春秋之意责备贤者，博客园的本次升级可以做得更好
从结果上来看，如果本次过程放在一般的互联网公司，不能不算是个产线问题，有差别的是博客园交流技术的氛围浓厚，不大会因此流失用户。不过博客园管理团队依然可以思考如下的问题。
1 对于升级后的技术方案，针对当前并发流量，有没有做过压测？
2 有没有事先评估升级过程中可能会出现的问题，并以此做了回退等预案？
3 高速开车换底盘的过程中，一般会用灰度发布的方式，一点点切流量，目的是对现有产线影响最小。本次升级，发布次数众多，是不是每次都是全量切换？
总之一句话，可以分析本次有哪些改进点？如果再做一次，怎么能做得更好。复盘问题，是为了让之后的升级更加平坦，也是为了让之后的升级更加自信。
2 自信更可以体现在框架层面
我经常见到阿里团队，在各种场合从框架角度介绍他们的组件或产品，而且不少框架和技术会在介绍后，影响面逐渐扩大，之后该组件或框架逐渐成为业内标杆。
比如现在我们要解决某个高并发等方面的问题，首先会想，阿里或其它著名互联网公司是否有现成的解决方案。与之对应，我所希望看到的场景是，博客园所采用的基于.NET的框架体系，也成为业内的标杆，如果有人在.NET方面有问题，首先会想，博客园对此是怎么解决的。这样的话，就单论技术层面，博客园的影响力也能进一步扩大。
虽然我是做Java的，对.NET不大熟悉，但从本次博客园相关官方文章里，能看到不少“docker”，“云”，“高并发”和“负载均衡”等热门词汇，这说明博客园所用的技术第一不算落伍，第二还紧跟技术进步的潮流。在这基础上，在不涉及到商业机密的前提下，博客园可以更为自信地在众多场合介绍自身的技术框架以及相关技术实践，比如介绍应对高负载的.NET体系框架方案。
希望不久的将来，能在诸多技术大会等场合，听到博客园技术人员能自信满满地介绍自己的框架，底下是顶礼膜拜的广大听众。
3 可以更自信地不断更新版本
本次版本迭代，影响面不小，但不能因此缩手缩脚，相反还可以更自信地完善技术乃至完善版本发布流程，毕竟博客园的技术储备摆在这里。
我期待的博客园发版流程是，首先举重若轻地通告，从某月某日某点到某点，进行发布；其次在发布过程中，虽然会出现个别功能故障，但总体不会出现大问题；最后是写篇文章总结，比如在本次发布过程中，用到了xx技术，从功能上做了xx提升，在性能上有xx改进。
这其实也是诸多互联网公司普遍流程，一般都是一月两版本，甚至更多，每次发布虽然重视，但绝非如临大敌。
发布时的自信来自平时的不断总结以及充足的预案，只要不停止探索，一回生二回熟，成功次数多了，自信心就慢慢提升上来了。
4 我们可以为博客园做点什么
在博客园发展的路上，我们不应该仅仅做看客。
第一，先不说写博客，就先说在评论别人博文时，应当注意影响，在争论不同观点时也应当尽量心平气和，毕竟在博客园发表不堪的文字，更会让博客园美玉有瑕。
第二，看到博客园偶有功能上的问题，乃至自己想到有改进点，可以找个合适的场合与博客园沟通。
第三，尽量多写些有质量的原创博文，比如在写文章前多找些素材，用词造句时多斟酌，多加入些自己的思考。
第四，如果以当前的能力，写不出足以留在首页的文章，也可以通过不断学习提升自己的能力，通过不断写作提升自己的文笔，这样文章的质量就慢慢提升了。
本人对.NET技术不熟，所以在本文里也不敢据此提出此方面的见解，在最后也希望能抛砖引玉，引出更多高质量的相关技术文章。
