干 货
- 9. 解决问题 - SMART法则
1. S - Specific
这里指的是目标一定要明确的( specific ) 不能够模糊, 时间上的 6 - 2 – 2 分配
2. M - Measurable
目标的可度量性。 制定的目标一定是可以度量的
3. A - Attainable
目标的可实现性。一个目标必须是可以实现的,或者说经过努力是可以实现的
4. R - Relevant
目标必须和其他目标具有相关性。 即一切努力都是为了一个结果,而不是为了行动
5. T - Time-based
目标必须具有明确的截止期限。 即一个目标只有在一定的时间内达成才有意义
- 14. 问题
1. 多种不同的 UI / UE ,不易管理和维护, 增加设计、开发、测试成本
2. 代码相似功能的重复实现,相同功能重复测试
3. 多项目间,相同服务需要重复建立,服务器资源会被浪费
4. 多项目部署有差异,难以维护
5. 各项目发布机制差异,难以建立统一、方便、安全的发布体系
- 15. 解决问题
1. 对 UI / UE 设计一份标准和规范, 通用于多项目中
2. 前端使用统一的解决方案, 使用UI标准控件(使用Dojo,上层自行封装UI组件)
3. 建立后端跨项目标准服务(MySQL、消息队列、LVS、静态资源服务 、GEOIP 等)
4. 定制环境项目结构标准, 降低运维成本,可用于未来开发统一的代码发布回滚机制
优点
1. 标准化能够降低开发、设计、测试成本, 提高项目产出效率
2. 统一的 UI / UE 对产物线的建立也有帮助
3. 服务标准化有助于虚拟化环境建立,方便项目的水平扩展,更有效利用服务器资源
4. 项目结构标准化, 有利于设计统一的项目生产发布/回滚机制
- 21. 解决问题
1. 建立代码规范(PEP8、Google Style Guide、JSLint 等)
2. 使用代码规范检测工具(JSLint、JSHint、Pep8Lint 等)
3. 代码审计(Redmine、Gitlab 等)
4. 代码文档注释 (Markdown、JSDoc、 Sphinx 等)
优点
1. 代码易读,上手快
2. 互相学习代码技巧
3. 人员互备
4. 避免脏代码
5. 有效降低BUG的出现
- 30. 解决问题
? 可用性
常用方法:
定时监控:监控宝、Cacti、 Nagios 等工具
实时监控: systats、htop、SNMP、自制警告脚本等
日志记录:系统、服务级日志、应用级日志等
描述 通俗叫法 可用性级别 年度停机时间
基本可用性 2个9 99% 87.6小时
较高可用性 3个9 99.9% 8.8小时
具有故障自动
恢复能力的可
用性
4个9 99.99% 53分钟
极高可用性 5个9 99.999% 5分钟
- 33. 解决问题
? 负载均衡 LVS、MySQL Cluster、CDN等
? 性能优化 项目-优化架构/性能分析工具、应用-性能测试、服务-优化配置
? 可维护性 标准化、虚拟化-OpenStack、同步-Puppet、自动化-自制脚本、平滑升级
? 应急容灾 单点故障、备份(软/硬)等
? 扩展性 虚拟化、数据切割、缓存池
? 容量规划 负载预期、数据监控警戒线等