Home | 简体中文 | 繁体中文 | 杂文 | Github | 知乎专栏 | 51CTO学院 | CSDN程序员研修院 | OSChina 博客 | 腾讯云社区 | 阿里云栖社区 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏多维度架构

第 7 章 风险管理

目录

7.1. 项目管理绕不开问题
7.1.1. 开发,测试与运维的关系
7.1.2. 压力问题
7.1.3. 重速度轻安全
7.1.4. 技术实力
7.1.5. 测试问题
7.1.6. 运维问题
7.2. 程序猿说的「优化」是什么意思?
7.2.1. 经验和能力不足
7.2.2. 给前人擦屁股
7.2.3. 先盖楼,后打地基
7.2.4. 使用新技术和不熟悉的技术
7.2.5. 最后总结
7.3. 制度、流程和规范的误区
7.3.1. 故事一
7.3.2. 故事二
7.3.3. 故事三
7.3.4. 故事四
7.3.5. 故事五
7.3.6. 总结
7.3.7. 案例分析:怎样避免电梯伤人事件再发生
7.4. 因果图在运维工作中的应用
7.4.1. 故障树分析(Fault Tree Analysis,FTA)
7.4.2. 什么是因果图
7.4.3. 为什么使用因果图
7.4.4. 何时使用因果图
7.4.5. 何处使用因果图
7.4.6. 谁来负责制作因果图
7.4.7. 怎样使用因果图
7.5. Incident Management(突发事件管理)
7.5.1. 突发事件处理流程
7.5.2. 事件处理方式
7.6. 监控的艺术
7.6.1. 背景
7.6.2. 概述
7.6.3. 怎样监控
7.6.4. 总结

涉及项目可能遇到各种不确定因素。它包括风险识别,风险量化,制订对策和风险控制等。

7.1. 项目管理绕不开问题

7.1.1. 开发,测试与运维的关系

开发,测试,运维不是三个独立部门,他们相互紧密联系,但又相互制约:

开发只负责写程序,将运行无误的程序提交至版本库中

开发不能私自将程序交给运维部署,也不能将编译好的程序给运维测试。

测试部只能从版本库提取代码,然后编译,打包,运行,测试

不允许测试部将代码交给运维部部署

避免代码没有经过版本库流入生产环境,线下与线上代码不一致

运维部负责部署应用程序,配置管理,只接受测试部确认无误的版本,部署代码只能从版本库中提取

开发 -> 测试 -> 运维 贯穿始终。

7.1.2. 压力问题

运维人员在互联网企业是最辛苦的,7*24小时待命,待遇一般。

很多程序写的非常差,BUG非常多,容易出现无响应,崩溃,开发人员一时也解决不了,只能硬上线。

最终这些问题都推给运维,通过运维手段去解决。这就让运维工作压力很大,状态紧绷,如履薄冰,如临深渊,随时随地处理故障。尤其是在双11这样的节日。

7.1.3. 重速度轻安全

国内互联网企业成长速度是第一位,管理粗放,怎么快,怎么来。

期初公司也是重视安全的,例如账号权限分级管理,操作也有流程,审批。但是企业要速度,各部门都面临压力。从一周一个版本到一天升级一个版本,程序的质量也在下滑,常常升级失败,反复回撤,为了效率甚至线上直接开放给开发人员权限,在线上修改。很多开发人员拥有数据库权限。

另一个问题是人员流动,很多人离职很长一段时间,权限都没有收回,仍能远程进入系统。

国内企业没有花钱请安全顾问公司的习惯,自认为自己有能力解决安全问题。运维人员也不会向公司建议找第三方安全公司,他们担心公司怀疑他们的技术能力。

7.1.4. 技术实力

你真的认为花高薪聘用的运维人员技术能力很强吗?哪些标着有BAT经验(大企业),渡过金的人运维人员能力很强吗?

很多运维人员仅仅是安装配置的水平,看了几本架构优化的书籍侃侃而谈。哪些在大企业干过的运维人员,也仅仅接触到平台的一角,他的权限根本无法窥视到全貌,无法使公司的运维水平上升到另一高度。

目前互联网企业运维人员普遍比较年轻,都是90后组成,这个年纪正是处于经验积累阶段和学习阶段,只有把系统当成了试验场才能学到东西,有很多事故是运维人员赶时髦,使用了一些新技术,不熟悉的技术(仅仅掌握皮毛),他们管这个叫“踩坑”。现在几乎没有企业招聘80后做运维,因为他们不能加班,不愿加班,抗压性/服从性较差。

由于运维技术能力,眼界见识。不是他们没有做(备份,快照,防篡改技术,防删除技术),是他们是想不出来解决方案的。

运维人员也不会建议公司请第三方公司或技术顾问,一是要花钱,公司不同意。二是,他们怕公司怀疑他们的技术能力。就这样很多问题被尘封了,只有出现重大事故的时候你才意识到他们能力不行。

7.1.5. 测试问题

首先回答你测试问题,测试人员的水平是整个团队中能力最差的,企业对技术人员重视重读顺序是,开发第一,运维第二,测试第三。人肉测试与自动化测试80%:20%的比例,掌握自动化测试高级测试人员薪水不低,很多企业不愿意或出于成本考虑,国内人力成本便宜大量采用人肉测试。无论是人肉还是自动化距离理想期望的测试结果还差的远。

自动化测试实施常常遇到很多问题(安全,技术,管理等等),例如

自动化测试攻城狮的技术水平有限(仅仅掌握了皮毛)需求的频繁变更让自动化测试脚本成为负担,最后不了了之复杂的技术栈,手机验证,图像验证,定位信息,摄像头操作,指纹,传感器,二进制位操作...... 一般测试攻城狮搞不了,卡在某个点过不去,最终放弃

导致自动化测试无法继续实施下去,一般除非是在职的高级软件攻城狮转测试攻城狮,他对需求清楚,功能清楚,协议清楚,数据清楚,业务逻辑走向清楚,否则一般的测试攻城狮根本搞不定这么复杂的测试脚本。企业也不舍得让这个开发主力转到测试部门去。

由于系统过于庞大,人肉测试所有功能是不现实的,所以常常是只测试新加入的功能或测试有依赖的功能。实际工作中,程序猿改动一行代码,牵一发动全身,尤其是那些复用的代码,加之程序猿人员流动,当时负责该功能人早已经离职(平均三年离职),你不知道改动一处,会有什么影响,所以程序猿很抵触修改老代码和其他人写的代码,宁可自己重新写,这又造成了脏代码,代码不断膨胀,反证三年后他也可能离职,让新来的程序猿接盘。所以常常是新加入的功能测试OK,隐藏很深的一个功能出现的故障,测试无法覆盖到所有功能。

很多时候故障不是测试人员发现的,多半是用户发现的,用户投诉到客服,客服反馈给技术部。

7.1.6. 运维问题

接下来回答你运维的问题,运维手段多着能,通过运维手段可以解决很多BUG问题。常用手段,例如万能重启,主备策略,负载均衡,快照,权限控制。我给你举几个例子。

如果代码容易崩溃,那就做一个自动重启的脚本,发现崩溃,立马重启。

如果代码并发有问题,例如做一个并发 10000的程序,结果程序猿水平有限1000并发就崩溃。就用负载均衡堆硬件,用10台服务器,先抗着

代码有漏洞,黑客入侵,修改页面植入木马。运维就通过权限限制文件只能读,不能修改。

代码有漏洞,导致黑客修改数据库数据。运维有多重解决方案,例如去掉修改权限,临时增加触发器,修改数据抛出错误中止操作

很多手段,这些手段可以为开发人员争取代码修复的时间