时间过去了10天，公司服务稳定性改进工作有了哪些推进？Till Now，在“服务稳定性”问题上，我们完成了两个工作：
- 故障紧急监控和处理的预案。这个预案经过了1次故障的检验，还比较有效。
- 完成故障紧急监控数据采集方案。确定了数据采集的项目，并进行了一次演习。也让相关技术人员熟悉了这些数据的意义，下次再出故障料可准确定位故障原因。
“治标”的工作差不多了，开始“治本”，昨天组织了一次后续质量改进的工作思路讨论。大体形成了如下思路：
- 必须按业务拆分
- 在数据库、应用服务器、分发服务器三个层面中，拆分的优先顺序是：数据库 –>应用服务器 –> 分发服务器
- 服务器采购
- 服务稳定工作列入各部门Q3重要工作内容
- 指标化：将服务可用性、性能指标化 ==> 落实指标的检查方法 ==> 落实指标日报 ==> 建日报处理和定期总结机制。
- 忘记了。。。（昨天开完会一直没空写既要，本子落单位了，所以细节忘记了）
其实都是很基本的问题，早应该随着业务发展不断重构的，甚至应该从一开始就做到的事情，拖到现在来做。亡羊补牢。
Related posts
进入五月以来，公司服务就接连出现稳定性问题，本来技术团队划归各业务线了，我人也从运营中心调到了产品中心，事情有专门的人解决，和我关系就不大了。但一个月来问题接连不断，按下葫芦浮起瓢，公司领导痛下决心要解决服务稳定性问题，这个问题涉及很多部门，于是我就被任命为这个居中协调的人了。
现在的情况是N条业务线共用分发服务器、数据库，还有一些业务共用应用服务器，甚至共用数据库连接池、NFS。交换机、网卡、apache、tomcat、程序代码都被当作怀疑的目标，而且每个环节的改动似乎都解决过问题。所以一团麻，很晕菜。
现在的思路是：短期加强监控做好应急预案，然后做出系统结构的调整，使得系统可控、稳定性得到加强。
凭直觉，在系统结构调整上有下面思路和原则：
- 按业务拆分：分发、应用、数据库、文件存储这几个方面看看如何拆分最佳。
- 划分系统运维和技术开发的界限和接口：减少系统运维管理的范围，增加开发团队管理的范围，使得出问题的时候能快速定位是网络、硬件、数据库还是程序的问题。
- 技术平台一致性：现在前端分发、app服务器、数据访问层都有很多技术不一致。但我估计现在去统一技术平台已经不现实了，只能借鉴一些混合编程的思路让多个技术平台和谐共处。
- 招牛人，办牛事：这忘记是当年哪个人告诉我的了，给我印象很深，而且越来越觉得有道理。
PS：上面的文字是前几天写的，目前系统的状况是：将前端分发服务器从DELL切换到IBM服务器上就好了，至少应付过了月初访问量最大的几天。接下来做系统结构的调整吧。
Related posts
继续昨天在“读《梦断代码》”里讲的“停止设计，开始编码”。
昨天和吴晓华聊这个话题聊了很久，有一些有意思的观点记录下来。
软件项目中判断一个文档是否需要书写的标准是看这个项目开发期之后这个文档是否还有持续的价值，如果尽在开发期内部的过程文档，那么这个文档就可以省了。
进一步解释一下“凡是有利于解放人力、开始写代码的决定就是好决定”：如果开发人员已经对需求和设计了然于胸，自我感觉可以进入Coding工作了，那么就应该进入Coding阶段了，这时候再去做的需求和设计文档多数就属于多余了。明明我都可以开始写代码了，那么拖着不动去写那些文档干什么呢？
把Coding的人和需求端的人扔在一起，让他们尽快开始产生有使用价值的东西，这才是王道。
对于CRUD（增删改查）就不要写需求和设计文档了。在越来越多的框架对于增删改查操作连代码都不用写了的时候，还写那些文档干什么呢？
Related posts
发现自己里coding越来越远了 — 前一段同时买了两本书，一本讲python编程的，一本《梦断代码》（Dreaming in Code）。结果很明显的更喜欢读梦断代码，而读不下去python的书。《梦断代码》就是一个程序员写程序员的故事书。我想这种书籍对于任何一个有开发经验，想往软件开发管理发展的人都是有帮助的，看看别人在开发中遇到的故事对自己是经验积累，了解一下软件项目有多难，为什么那么难。
我刚读到第二章，里面提到的观点非常吸引我：
停止设计，开始编码！
“在网景公司，写代码是重中之重，所以只要是有助于解放人力、有助于开始写代码的决定就是好决定。”
“赫兹菲尔德的总是坚持让开发者们停止设计、开始编码 — 至少不要等到地面完全凝固才开始。赫兹菲尔德告诉我：我的风格是赶快干起来，然后把它变成我们想要做的大东西。这不是平庸之作，是个大东西。不过总的开始干吧！要点在于激情开干。”
Related posts