1、发邮件一定要短，主题明确，内容少，界面不要提供下拉，不然没人看。6.6
2、管理要了解员工的配偶的职业规划。6.6
3、会议纪要要在会上总结说明，会后30分钟内发送。6.6
4、我们的竞争很激烈，马上要面对印度人力成本竞争，外包成本竞争，云服务竞争。6.7
5、感觉部门的技术问题攻关很弱势 6.8
6、考虑问题不仅要站在客户的角度，还要站在自己部门的角度 6.9
7、防呆措施，可以从声音提示，自动打电话，自动电话确认入手，如按1# 6.9
8、以亚当斯密的专业化理论为中心，引入竞争机制。6.12
9、外包管理考虑场地责任，所以尽量离场。6.19
10、管理有时候是个暴力的过程，直接给你安排任务就好，你不接就给你记一笔。 6.22
11、解决问题还是需要具体问题点，问题不能太宽泛，领导也不容易解决的那种不要提。7.22
12、问题要分析，推动解决的时候建议附上流程图。7.27
13、责任范围要分清楚，例如SLA中，单个故障不算，批量的算；系统管理员操作的算。7.27
14、操作稽查场景要全覆盖，单个场景操作次数的覆盖比率为5%；要现在领导的角度来看，所有操作都是可查的。要有统一的规则，账号、权限、使用人员、登录系统，要做脚本稽核。7.27
15、CI备份管理流程责任重大。7.27
16、各块业务的可靠性到底达到多少？工具在降低风险上的空间。7.27
17、不能因人设岗，而是因岗设人。7.27
18、质量上规避重大风险，操作上是否防呆。防呆工具的推广。7.27
19、信息传递遗漏的准确率。生产环境有多少信息传递？7.27
20、工作的时候，要找到机会点或创新点，先讲目标，再讲措施。7.27
21、用防呆工具来替代1+1。7.27
22、定下脚本开发导致问题的责任分属，现有脚本上线有哪些风险？7.27
23、牵引组内做长期有效的工作，才是有价值的。例如保障，总责任人，重大故障等，要找到岗位的稀缺性和岗位机会。7.27
24、定的目标之后，是否可操作？例如实际变更根据新的范围定义后，我们占比为多少？
25、找到彻底能改进问题的点。通过一个点，找到通用类问题。8.07
29、消灭命令行操作。拿到root权限后只能做相关操作，什么样的场景我可以用，什么样的场景不行。8.07
30、不在操作指导书里面的内容就是变更异常，异常要第一时间升级。8.07
31、为什么不按操作指导做？一定要找到合理的动机，解决根因问题。8.07
32、这类问题为什么我们没有稽查到？8.07
33、每个例行化工作的异常率有多少？建立基线。对没有异常的操作指导，进行稽查。8.07
34、问题发生3个月后，建议组织一次审视，确认问题已经彻底整改。8.07
35、稽查覆一层指标是全网覆盖率，然后是单个业务项的覆盖率，最后是操作数量覆盖率。8.07
36、质量管理其实类似保险，我们无法承受1、2级故障带来的损失，例如1000万，但是买保险只要几千。所以我们所做的工作，可能成本比较低，但是实际上产生的收益是很可观的。
37、脚本的后续发展趋势是产品，度量业务效果是多少人使用了多少次。
38、例行工作数量减少，脚本数量增加（荣誉感）
39、学习满广志
40、主管要关注筹措预算
41、从点到势的进行宣传和推广
42、使用开源的情况
43、视角上要提高一层，利益要点要站在给黄总、苏总汇报的视角。
44、共享的主要问题点：
划线，超过线的就是A；操作数据不重复，如何确保；如何设计为派单式，量化的考核里面怎么引入用户评价。0911
45、我们的目标是走向自动化，最终走向智能化。优化劳力结构，逐步提升自动化水平。我们前面是有榜样的，不要完全摸着石头过河。
46、不管是谁，若提出要配合稽查、验证、调查、取证、确认的事情，一定要找主管去确认是否可以配合。避免被坑。0912
