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