下周继续

《架构即未来》第三章读书感悟
1：组织中的两个重要的要素：规模和结构，会影响沟通、效率、质量、标准和责任
2：经理的职责：
确保工程师们在有价值的项目上产出高
确保完成行政管理工作
确保掌握项目和问题的进展状态
3：多关注 警告的信号：沟通不顺、生产率低下、士气低落 团队规模太大的信号
不满意业务合作伙伴、微观管理的经理、过度劳累的团队成员
4：职能型组织、矩阵型组织、敏捷型组织
创新能力可以作为组织选型的一个重要评价指标
通过市场响应速度、高质量的新功能和高可用性的服务来衡量

《架构即未来》第七-八章读书感悟
第八章
详细描述了【问题】与【事故】的关系，以及如何处理，这是任何技术组织最重要的过程之一。
1：事故是生产环境的问题，问题是事故的原因。
2：快速恢复服务可能导致丢失一些取证数据，而这些数据对问题管理极为重要，思考应该给多少时间来收集数据以及收集哪些数据。
3：事故：开启、解决、关闭、 问题：开启、定位、关闭
4：定时对发生过的事故和问题进行回顾和总结。
5：一个事故总有多个根源，并不是单一问题引起的，我们推荐事后 最小化事故监控时间、最小化事故解决时间、确保事故不复发以及最小化事故风险。

第七章：
1：过程：软件工程中，人、工具、方法的结合，解决软件工程中的问题
2：过程的成熟度：对采用持续改进的组织体现在能力级别的提高。

对使用阶梯式表达方法，体现在成熟度提升

3：确定最佳过程数：从小到大周期迭代。团队民主决定。
4：过程应该有一个负责人，定时维护。

第七章：
1：过程：软件工程中，人、工具、方法的结合，解决软件工程中的问题
2：过程的成熟度：对采用持续改进的组织体现在能力级别的提高。

对使用阶梯式表达方法，体现在成熟度提升

3：确定最佳过程数：从小到大周期迭代。团队民主决定。
4：过程应该有一个负责人，定时维护。
第八章
详细描述了【问题】与【事故】的关系，以及如何处理，这是任何技术组织最重要的过程之一。
1：事故是生产环境的问题，问题是事故的原因。
2：快速恢复服务可能导致丢失一些取证数据，而这些数据对问题管理极为重要，思考应该给多少时间来收集数据以及收集哪些数据。
3：事故：开启、解决、关闭、 问题：开启、定位、关闭
4：定时对发生过的事故和问题进行回顾和总结。
5：一个事故总有多个根源，并不是单一问题引起的，我们推荐事后 最小化事故监控时间、最小化事故解决时间、确保事故不复发以及最小化事故风险。

第九章：
危机犹如类固醇，既可以使公司更强大，也可以破坏业务，如果不积极管理危机，会毁掉公司在客户、组织及其技术应用平台与服务方面的扩展能力。
要尽快和有效地解决危机，必须采取某些措施来控制混乱。
最有效的领导人在危机中保持冷静，在整个危机管理的过程中能有力地维持秩序。他们必须有敏锐的业务头脑和技术经验，可以承受压力。
危机处理小组由危机管理者、工程经理和高级工程师组成。此外，向工程经理报告的工程团队也参与解决问题。
危机管理者的角色是维持秩序和遵循危机解决问题、升级和沟通的过程。
工程经理者的角色是管理其团队，并向危机管理团队报告进展情况。
工程团队里高级工程师的角色是帮助危机管理团队提出和审核有关问题原因的假设，并帮助确定最合适的快速解决方案
个人贡献者工程师的角色是跟着自己的团队，确定快速的降决方法。建立和评估问题原因的假设，向自己的经理报告进展状态，他的经理应该是危机管理团队的成员。
危机管理团队成员应该在作战室面对面地沟通，如果不能进行面对面地沟通，团队应该使用电话会议和聊天室。
作战室最好紧靠运维中心，以帮助处理危机。
在危机管理过程中要清楚地定义升级和情况通报。危机发生后，在处理过程中应定期提供状态更新，直到确定和修复所有问题的根源为止。
在危机的事后处理过程中应该积极检查、发现和管理一系列的后续问题，并以主事后处理和子后事处理的形式分主题进行，针对所有发现的问题全面出击。
第十章：
当员工需要触摸、旋转或者戳碰任何的硬件、软件或固件时，变更发生。
变更识别对小公司来说是简单的过程，专注于寻找最近的变化，如果发生事故可以回滚。
有效的变更识别过程的最低限度应包括变更时间、目标系统、预期结果以及联系方式。
变更管理的目的是通过控制生产发布和记录活动，限制变更的影响。
变更管理包括以下几个阶段：请求、审批、调度、执行与日志、验证、回顾。
变更请求是过程的起始，应该包含以下信息：系统或子系统、预期结果、如何执行、已知风险、已知的依赖关系以及与其他变更或子系统的关系。
在变更先进的变更过程中，变更请求还包含有关风险、回报、建议的日期等信息。
变更审批验证所有信息的正确性，只有提出变更请求的人才有权力做出变更。
变更执行和变更识别过程类似，但包括变更数据库的开始和完成时间的记录。
变更验证确保变更满足顶期效果。如果先败可以回滚，如果取得部分效果，可以升级。
变更回顾是变更管理团队对变更过程和结果的内部评审。它分析数据，从而了解变更的速度、失败率、对响应市场时间的影响等。
在变更控制会议上，会对变更进行审批、调度和执行后回顾。该会议通常由运维主管或基础设施负责人主持，每个工程团队和面向客户的业务团队作为成员参与。
变更管理过程应由变更管理小组以外的团队来评审，以确定其有效性。每季度或年度审查是适当的，审查应该由首席技术官/首席信息官和公司高管进行。
在实践持续交付的公司里，变更管理把规则通过代码集成在自动化测试系统中，以完成自动化发布。在持续交付解决方案中，风险分析、变更识别、变更审批和风险水平都是内在的。

第十三章：
1：解决闭门造车的问题：跨部门提供不同观点的组进行设计
2：JAD 与 ARB，JAR 是负责 ARB是责任
3：JAD 的成功关键在于过程是完整的，严格坚持准入与批准标准
4：ARB 成员应该被视为领导人，受到应有的尊重，并有某些应用或架构领域的专业知识

第十四章：
1：敏捷团队应该自主行动，应该拥有自己的服务和产品涉及
2：ARB 和 JAD 保证跨团队的，敏捷团队自己保证。
3：敏捷团队应该足够灵活，通过积极的分享知识，考虑使用 ARB 来验证架构原则的采用和合规情况，定期召开会议回顾最近发布的设计

第十五章：
1：自建与采购选择不对会破坏有效扩展能力，同时损坏股东价值，浪费时间和精力，IBM、MAC 的历史事迹。
2：应该自建还是外采要回答四个问题：
1）：自建的组件是否能形成具有战略性差异化的竞争优势
2）：我们是该资产最好的所有者吗？
3）：该组件竞争情况如何？
4）：自建的成本效益如何