架构即未来
2019-01-28 17:08:27 0 举报AI智能生成
架构即未来全书思维讲解，全面的架构原则分析，通过对架构的分析形成团队管理、个人管理，领导力管理以及架构原则的详细分析
作者其他创作
大纲/内容
管理
1、管理是有关执行和实现组织目标、使命、愿景的必需的所有活动<br>2、以明智与合乎道德的手段来完成任务
项目和任务管理<br>
好的管理在预算内完成任务
把目标分解成具体的任务来支持项目
5-95原则
5%的时间完成一个充足、详细、保守的计划，同时承认这个计划不完备
95%的时间用于应急演练和应付突发事件
不要增加制定计划的时间，但是可以利用5-95原则来分配时间
团队的持续提升和改善<br>
播种
增加更好的人才
施肥
培养和发展要保留的人才
除草
淘汰表现不佳的人
度量、指标和目标评估
不去度量就无法改善
度量主题
成本<br>
质量
响应时间<br>
生产率
可用性<br>
关系、思维<br>、商业
在业务主管与产品团队之间建立有效的合作关系
以正确的思维方式研发产品<br>
关系<br>
技术主管
技术团队对结束日期提供早期反馈<br>
反复出现相同问题<br>
技术团队成员的工作衡量指标
技术方案的选择基于商业利益还是技术实现<br>
技术团队是否了解什么驱动业务
技术团队理解面临的挑战、风险、障碍和策略
技术组织
IT组织模式
产品组织模式
技术是产品的一部分
产品就是业务
技术指标
cap
高可用<br>
架构原则<br>
目标
具体的
可度量的
可达到的
现实的
可测试的
架构原则维恩图
制定原则的步骤
确保所有参与方应用此原则<br>
通过原则与公司愿景、任务和目标关联，创建一个成功的因果元素
为原则拟定主图，构建韦恩图，显示重叠部分
把大团队画成小团队，然后由每个小团队分别提出他们的原则
把团队集合起来做个小型展示，由小团队来修改他们的原则
经行多轮陈述，选择重叠原则<br>
投票选出原则并排序
普遍的架构原则
N+1设计
确保任何系统再出现故障时，有一个冗余的实例
回滚设计
禁用设计
通过开关可以禁用
监控设计
监控和日志收集
设计多活数据中心
保证渡过任何在地理上可以隔离的灾难和危机
允许托管服务多地独立运维
使用成熟的技术
异步设计
无状态系统
状态有上下关联性，消耗存储、计算以及同步依赖
水平扩展非垂直扩展
设计至少要有两个步骤的前瞻性
非核心则购买
使用商品化硬件
小构建、小发布、快试错
故障隔离
确保服务、子服务的故障不会影响到其他的服务
自动化
自动部署、构建、测试、监控、报警
联合架构设计和架构审查委员会
跨部门合作
敏捷架构设计
团队组建
先招聘的是软件工程师、产品经理、质量保证工程师、DevOps工程师、最后是架构师
分配资源，尽量不要共享资源池
风险管理<br>
风险
风险由现在的状态决定，与过去的状态无关
风险是个累积过程<br>
步骤<br>
1、测量风险
直觉法
交通灯法
故障模式和影响分析法
FMEA风险评估
2、风险管理
组织
可扩展性组织
定义角色
执行人员的责任
执行人员的责任
首席执行官
首席财务官
业务部门负责人、总经理、产品线负责人<br>
首席技术官/首席信息官<br>
独立贡献者的责任
架构师的责任
工程师的责任
基础设施工程师的责任
质量保证工程师的责任
系统容量规划师的责任
RASCI工具（矩阵）
R:负责<br>
A:批准
S:支持<br>
C:咨询
I:知情
管理
推
领导
拉<br>
组织的设置<br>
重要性
沟通
效率
质量
标准
责任<br>
规模
6~15人
事项检查表
确定经理的经验水平<br>
计算工程师在公司的工作年限<br>
计算工程师从业工作年限
根据经理的责任估计工作量<br>
寻找因规模太小而无法发挥作用心存不满的业务经理<br>
发现因规模太大而效率地下的现象<br>
确定如何差分代码<br>
按照服务拆分<br>
尽可能的把基类分割
在代码库中加入提醒<br>
确定新的经理
考虑内选还是外聘
设定一个紧迫的时间来完成<br>
分析团队与其他部门间的关系
与其他部门负责人讨论拆分方案<br>
协调本团队与其他团队的关系<br>
通过联合通知的方式向全部门通告
组织结构
职能型组织<br>
矩阵型组织<br>
敏捷性组织
创新模型
领导力模型
自知之明<br>
身先士卒<br>
谦虚谨慎
以人为本，使命为先<br>
决策英明，以德服人
用人不疑
与股东价值保持一致
变个型领导
愿景<br>
使命
目标
可扩展的过程
解决的问题
在生产环境中发现问题及变更
如何应付危机<br>
在设计之初考虑扩展性
理解和管理风险<br>
自建系统和采购系统<br>
确定系统规模
什么时候发布产品？什么时候等待发布<br>
什么时候回滚？如何应付突发<br>
过程<br>
持续改进过程
CMMI
时间实施过程
故障和问题<br>
可复发性故障是可扩展性的天敌<br>
通过定义适当的过程来解决
活动
区别故障和问题并相应的跟踪
根据故障的生命周期，适当的分类、关闭、报告跟踪故障
问题和故障跟踪系统
建立每季度的故障回顾机制，从过去的错误中学习
建立强大的事后处理机制，以发现所有根源问题
故障（事件）
定义
可能会造成服务终端或服务质量下降的非标准服务操作事件（任何降低服务质量的事件）
故障管理
以对业务和用户的影响尽可能少而且经济有效的方式，尽快回复服务正常的操作
问题（根源）
定义
不明原因引起的一个或多个故障，往往被确认为多个类似故障的结果<br>
问题管理
目标是尽量减少问题对组织的影响<br>
事故管理<br>
活动
监控和记录事故
识别问题
记录问题
分类和初步支持
调查和诊断<br>
解决方案和恢复服务
关闭事故
事故所有权、监控、跟踪和通信
实施
DRIER
D：Detect
通过监控或客户联系检查事故
R：Report
报告竖骨，记入负责跟踪全部事故、失效或其他事件的系统<br>
I：Investigate
调查事故以确定应该做什么
E：Escalate
如果事故在规定的时间内没能解决，尽快升级
R：Resolve
通过回复最终用户需要的功能和记录所有的信息，为解决试过做跟进
DRIER流程控制模型
问题管理
确定系统回复前需要收集哪些信息
确定你愿意在回复服务前收集多少诊断信息
确定当你需要问题根源分析比系统恢复更重要时，你允许系统失败几次
如果有冲突，什么时候应该恢复系统，确定谁应该做出决定
事故和问题生命周期
事故生命周期<br>
开启
当事故或生产中事件发生时
解决
当服务恢复时
关闭
当生产中的问题被关闭时
问题生命周期
开启
当与一个事故关联时
定位
当确定问题根源时
关闭
当问题已经在生产环境中得到解决并获得验证时
施行每日事故例会制
事故分析、分配、跟踪
施行季度事故总结机制
检查事故和问题管理过程的完备性和有效性
事后处理<br>
事后分析过程
事后分析之前
时间轴阶段
时间分析阶段
行动阶段<br>
事后分析后续<br>
任务列表<br>
人/解决问题的时间
过程/解决问题的时间
技术/避免事故的能力
技术/监控到问题需要的时间
危机管理和升级<br>
生产环境的变更管理
变更
调整产品或系统，以提高价值或扩大容量的行动
变更管理
变更识别
限制编程影响<br>（变更日志）<br>
变更的准确日期和时间<br>
将要发生变更的系统<br>
实际的变更<br>
变更期待的结果<br>
变更人员的联系方式<br>
变更日志
变更控制
持续交付（CD）
更小、更频繁的发布<br>
目标
确保在有效和及时处理变更的过程中采用标准化的方法和过程
变更日历
未来长期计划中需要标注的变更事件
变更回顾
提交变更请求的数量
提交成功变更请求的数量<br>
提交失败变更请求的数量
因变更请求引发事故的数量<br>
由于未能验证，终止变更或回滚的数量
执行一项变更需要的平均时间
变更控制会议
自动化交付系统
预留空间
预留空间=（理想使用率x最大容量）-当前使用量-E(增长（t）-优化项目的收益(t))
预留时间=预留空间/E（（增长（t）-优化项目的收益））<br>
0 条评论
下一页
