2013年总结

再过1个小时就是2014年了。

记得谁说过,当你回忆往事的时候,说明你已经老了。

2013年好像啥事情都没做,经历了忙碌2012年,2013年是调整的1年。

总结起来2013年看了很多闲书貌似,然后还从台湾带了几本闲书,顺便去了趟台湾玩,好了,中港澳台都去过了,也算周边中国了。

10月又去了次四川成都和九寨沟。 看了九寨沟和黄龙的晚秋风景,回来后对三里屯东5街的银杏黄叶完全无感了,可还是看到那么多男男女女女来这里拍照。

这1年貌似出差也挺多,其实我这人挺不爱出差,更不怎么想去IDC,不过这1年就必须这样啊。

2013年也看到一张搞笑的运维图片。要都这样运维工作怎么去完成了,要从上层设计的时候避免任何的单点故障,千万别有侥幸的心态,一台服务器安全运行4,5年那都是很难的的,特别是业务变更多的公司。

Advertisements

Engineering Reliability into Web Sites: Google SRE

Engineering Reliability into Web Sites: Google SRE

Alex Perry

alex.perry

原文:http://research.google.com/pubs/archive/32583.pdf

概要

这个主要讲的是在google的网站保障工程师(SRE, 国内应该称之为应用运维),解释了他的目标和描述它会遇到的挑战

在mountain view, zurich, new york, santa monica, dublin 以及 kirkland的SRE团队管理着许多google的服务和网站。

他们利用分布于全世界数据中心的基于linux的计算资源。

主要内容

  • 根据不同站点来划分组
  • 网站的失效和不可靠会耗尽人力成本
  • 工程师应该专注于消除未来的工作,而不是像救火队员一样,要有一定的预见性。
  • 一个新项目是如何转移到SRE团队的。这个主要是一个新项目是如何从开发转到SRE的。
  • 对于用户量的快速增长要有计划。主要是根据现有的增长速度来进行预测。
  • 估算SRE团队最合理的人数

网站 — 是一项综合的部署

  1. 团队需要确定用户可视化的(可测量的)的在线时间和质量水平
    1. 这个需要掌控所有相关软件和系统的情况
  2. 对于各个组件有深度的了解和知识是很有必要的
    1. 这是一个需要比较陡的学习曲线,这种曲线大部分由于各个组件的复杂性造成的
    2. 要持续的再学习,因为网站是一直都在升级的。要想一劳永逸是不大现实的。
  3. 对于使用共享组件架构的特殊性
    1. 要确定那些共享的组件有很好的可靠性。比如一个网站所用共享的中间层和底层组件。

Reliability – it just works

  1. 最小化的人力成本的使用
    1. 团队管理监控和开发都需要自动化。自动化监控和部署。比如puppet,nagios这些工具
    2. 这个意味着使用脚本工具和数据分析工具。一些初始化脚本和安装工具等等。
    3. 大部分失效都需要适当地自动恢复。当出现问题了能够自动恢复。比如自动切换和重启。
  2. 把更高的风险转移到方便处理的时候
    1. 在工作日之前学习那些已经处理掉的风险(Learn of age mortality risk during preceding workday)
    2. 那些刚开始的风险需要完美的解决,防止影响google现有的业务(Infant mortality ideally also avoids Google meals)

工程师—不是管理员

  1. 对于报警和通知规范需要细致的定义
    1. 在发出通知之前可能错误已经导致了问题。
    2. 通常定义报警和通知规范需要通过多个层次,多个级别,多个角度进行。这个主要是从多个维度来定义。
    3. 这些定义可以通过设计来手动和自动的进行增加。这个就需要自动化的管理平台
  2. 对于项目的升级和扩展进行负责
    1. 计划所有的需求,同时要重视效率。
    2. 文件的bug可以在合适的时候进行修复。

新思维: SRE是兼职的开发人员

  1. 一般工程师都会一周抽一天去做开发
    1. 在其它地方可能会就要利用晚上或者周末时间。
    2. Google的工程师每天都有20%的时间来做这些项目。
  2. 开发者有时候会有其它的想法
    1. 有多少老的网站的工作是需要快速回退的。
    2. SRE有20%的空余时间来做项目,这些项目有趣吗?

最初,网站是需要重点维护的

  1. SRE给出可以自动化的日常事务的指导
    1. 通过消除重复性的工作来减少工作负荷。
  2. SRE指出开发文档中的错误和疏忽,但是我觉得这个最好在开发阶段就指出来。
    1. 开发人员也许会在其它地方也同样给你帮助。
  3. SRE建议附加的长期的监控
    1. 这些建议应该覆盖所有的间隙和跟踪性能。
    2. 管理员需要充分的可信赖的监控。

上线一个新网站是一个契机

  1. 你不要对那些新上线的20%的网站而后悔
    1. 页面调度器可以发出比你想象的更多的警告(一般情况下网站会在任何时候发出警告)
  2. 但是在上线的几周内,SRE的专业知识是很有必要的
    1. 开发人员的工作压力可能降低到1%
  3. 剩余的1%可以在任何时候做
    1. 仅仅写好好的文档可以让别人方便接管
    2. 许多工程师都选择继续使用页面调度器

把网站推给了SRE

  1. 这个决定是逐步变为长期的
    1. 对于一个网站的日常工作会变得减少
    2. 通过优化和分析可以使软件逐步改进
  2. 开发人员仍然会保留很少的关注对于这个网站
    1. 工作主要对针对下一个版本,修复已知的bug
    2. 老的在线的版本会逐渐不重视了
    3. 一个明显的特征就是把这些网站推到SRE这边来进行维护了

on call – more than quick fixes

  1. SRE团队人员需要轮流值班
    1. 修复那些现在还不能自动修复的问题
    2. 通过累计发生的问题来确认优先级
    3. 把诊断的问题和解决方案进行文档话
  2. 一个永久的解决方案需要很长的时间才能完成
    1. 发现文件bug,开发补丁,测试,代码复查,提交
    2. 集成,版本和发布要进行日程安排
    3. 为什么要花大量的时间来做这些呢? 这个主要让SRE的变的更有条理。对于类似X度这样的公司整个运维部门整天就是忙上线实在是无语。

名声 – 越来越多的用户

  1. 网站的稳定性不能由于升级而降低
    1. 网站架构通常是可伸缩性和健壮的
    2. 这些是google软件工程师的核心技能。
  2. 算法的性能是成比例的扩大的
    1. 所以修复bug也要监控和自动操作
  3. 实际上工作压力是随着问题的增加而增加的
    1. 有效的人力确实被现有人数限制着的

事情的增加 — 更多的用户

  1. 工程问题可能会根据用户等比例的放大
    1. 软件中新的功能没有被完全实现。O(1)
    2. 在常规的硬盘挂掉导致服务器down掉。O(u)
    3. 内存中的宇宙射线,新用户的哈希是有效的。O(u2) 这个意思就是说由于算法的问题,导致本来2个用户应该是不一样的哈希结果,但是却变成一样了。这一般要到非常大的用户量才会发生。
    4. 以太网中的比特传输是无序的,所有包都是通过CRC校验的。O(u3) 这个的意思是由于网络流量非常大,以及并发特别高。导致CRC校验也会产生冲突。这得多大流量啊!!!
  2. 更高等级的请问题通常不太可能一开始就发生
    1. 因为他们是有可能发生的,但是是无形的,因此很难被修复。
    2. 但是它们发生后会使问题扩散的很快。

第一次出现 — 对于每一个小时

  1. 想象每10天用户数量就会翻倍
  2. 考虑网站的O(u3)问题
    1. 瞬时的页面比例 = exp(date /5)/k
    2. 累计的页面访问数量 = exp(date/5)5/k
  3. 在你收到第一个页面产生的问题
    1. 期望的第一个页面的时间 = 5 in (k/5)
    2. 在未来的3个星期内,它会每小时报告一次。

多久可以扩展一个网站

  1. 这个主要是看解决问题的决心
    1. 多长时间可以确定问题,并且一个一个解决
  2. 要早期的发现bug需要好的工具
    1. 远程诊断和相关维护的日志
    2. 在发现第2个警告前就要开始解决第一个问题。
  3. 一次就修复bug,这个需要快速地测试
    1. 确认以前的bug不会复现

false positives, false negatives

  1. 谨慎小心的报警会导致一个危机
    1. 导致在压力下会一有问题立即去修复。
    2. 这相反会消耗工程师的时间和精力。因为报警过于琐碎而浪费了工程师的精力。
  2. 通过对于归档数据的分析进行优化
    1. 监控系统通常是不出声的。(正常的时候当然不会报警呀)
    2. 新增加的问题会更容易被发现
    3. 一般问题马上会被侦测到,那网站会变的更快

轻量的SRE团队(Lower bound on SRE team size)

  1. 每周的一天:做自己的项目,就是那些20%没被分配的时间
  2. 每周的1天: 休息,公司事务, 志愿者,或者病假
  3. 每周的1天: 对于网站的特别培训, 学习网站的更改信息
    1. 所有的每个网站培训都是相同的对于团队大小。
  4. 每周的2天: 网站分析,计划相关内容,维护等等
    1. 对于一个网站来说每周需要多少人力?
    2. 这个是确定团队人数的低的边界。

估算on call能覆盖哪些需求

  1. 工程师能否对于一个警告不响应
    1. 如果是,那我们需要实现工程师冗余
  2. 你网站页面服务的失效比例是多少
    1. 有可能会超过10%,很难达到1%
    2. 5%会使用4种冗余的方法来达到99.999%
  3. 对于任何一个报警只能有一个工程师响应
    1. 使用优先级或者选举的手段来避免浪费精力。
    2. 那其它ON CALL的SRE不会感到困扰

网站是否需要合并

  1. 比较网站的工程操作和oncall需求
    1. 可能会让一个SRE团队来对多个网站值班
    2. 培训开销:每个工程师都要学习所有负责的网站
  2. 这种合并整合是一个长期的目标
    1. 有一些观点是,每个网站都会最终停止更新
    2. 然后工程师专门对付较低优先级的问题
    3. 比如一个网站,最终维护的趋势是变为0
    4. 但是覆盖需求的on call人员是固定不变的。

总结:

  1. 网站的有效性是需要不间断的工程性 的努力
    1. 这个比软件实现需要更长的时间段
    2. 工作要有短期目标和长期目标是非常重要的
  2. 大型网站需要一个管理员团队
    1. 如果他们一直都很忙,那就没有空间成长
    2. 让一个团队管理多个网站是比较经济的
  3. 撰写和修改软件来替代管理工作
    1. 随着网站的扩展自动化的好处会越来越多
  4. 团队尽量要小,每个团队都有一个合适的大小

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com

twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA

应用运维和系统运维

运维工作对于很多人来说其实就是看一个看说明书的工作。从man page到各种软件的readme,install file都要看。理论上看着挺简单的。但是接触多了这就分了应用运维和系统运维。

我这2个都做过。老实说系统运维是更轻松的,毕竟系统级别的改变一般是比较少的,比如碰到系统内核升级,centos版本升级,数据库版本升级,CDN改造这些不是一直要做的事情。这是一个长期过程。系统级别的更改往往是非常慎重的,得经过非常多的测试,比较和优化才可以进行上线。

系统运维首先需要保证的就是系统的稳定性,毕竟所有应用都是架设在系统平台上的。所以系统运维既是一个基础的工作,又是一个非常重要的工作。说基础是因为它是一切应用的基础的,说重要是因为要是系统不稳定,那何谈应用的稳定性呢?系统稳定性,这个基本是由于驱动导致的,有些驱动问题在一般情况是看不到的,但是一旦在高并发的情况下,比如AS5对于某些品牌的网卡在大流量下网卡会崩溃掉。还好linux的驱动开发者还是非常热心的,一般很快有patch会出来。但是还是由于我们测试不够仔细才会有这样的问题产生。

系统的优化也是非常重要的,曾经有个以前同事说他们的游戏服务器压力很大,主要的压力是在io上,其实就是磁盘上。vmstat看到io部分值非常高。这个有应用导致的,也有系统平台和系统软件导致的。比如这个问题就是由于使用sendfile读写大文件,而改成使用普通的read方法就立刻降下来了。但是有时候还有缓存读写等等原因。另外一个优化是对于系统参数和网络参数的优化。其实这些都是要根据这个服务器具体跑什么应用来决定的。

下面说下当初做应用运维的日子。在那个SNS网站的日子,我就彻底经历过了。应用运维是要保证应用层的稳定性。但是对于大型SNS网站,网站更新是一个常态的过程。于是你就会发现发布成为一个天天进行的东西。但是发布和到底怎么发?发了后的预期结果是什么?到底会对现有应用有什么副作用?这次发布是代码的发布还是一个新的应用组件的发布?

于是应用运维首先要建立一个严格化的发布和测试流程。但是有时候开发会用点非常新的软件为了实现产品需求,但是应用运维如果不知道这个东西,那一旦出了问题你就没法一下子确定问题的症结就麻烦了,特别是对应用的稳定性造成影响后,那你身上的压力就特别大了。

这次velocity会议上淘宝运维的九峰同学的PPT还是非常不错的。基本上对于应用运维做了一个很好的总结。一个好的应用运维基本要在产品设计阶段就要加入进去,这个时候加入进去对于你理解业务逻辑是非常有好处的,同时你可以发现某些肯定会对系统稳定性产生问题的设计提出自己的修改意见,毕竟产品一般都是不怎么懂得技术的。当然我们更关注的是产品的稳定性,至于产品要达到什么效果那是产品仔细考虑的东西。

而在开发阶段,那需要跟开发商量通过哪些现有的开源程序可以达到产品需求,这个时候尽量使用那些你了解的,稳定的,最好版本已经超过0.5的那些软件。而不要使用那些你都不知道它的工作机制的软件。这个过程通常比较容易,毕竟开发也想这是一个稳定的应用,但是有些激进的开发者往往会自己造轮子,那你得明白这个轮子是怎么工作的。曾经在的那个视频公司就有这样的问题,很多东西都是开发自己造的轮子,连数据同步这些都是自己造的,但是由于不够稳定,给我工作造成了极大的麻烦。

测试阶段,分为功能测试和压力测试。大部分公司都是这样分为2种,如果只有功能测试的公司,那你得注意了,应用的稳定性跟压力有时候是成正比的。

发布阶段,这个比较简单,备份备份备份,可回滚可回滚可回滚。

前面这些其实都是应用运维的先期工作,应用运维真正的工作现在才开始呢。通过各种工具查看系统和应用状态。基础的有:cpu使用率,内存使用率,io情况,网络连接数,网络流量等等。业务方面的可以看下现在的pv,uv以及你自己定制的各种事务流程。而这些数据不光是看应用是否有问题的,而且还是以后扩展这个应用还是砍掉这个应用的核心数据。

应用运维的报警工作,比如pop3服务是否正确,应用的内部调用是否正常,有阻塞没? 这些要是能做到预警机制那对你非常有利,在运营还没发现问题的时候你就解决了问题,那不是很好阿。当然这些你需要对这个应用的内部逻辑非常清楚才会方便的建立好。

通过上面你可以发现应用运维包含了部分系统运维的工作。系统运维对于系统软件的工作机制和文档和各种操作系统发行版的文档要非常熟悉。而应用运维有时候更象是一个架构师和应用说明书。

具体的troubshooting就不说了。

###########################################

Best regards
Timo Seven
blog: http://www.timoseven.com
twitter: http://twitter.com/zauc

Linux System Admin & MySQL DBA

安全运维体系

如何做到:

  1. 部署容易: 做好部署脚本,包含各种不同的应用的部署脚本

  2. 易维护:错误列表需要做好,各种安装文档作好。

  3. 更安全:做好安全协议和各种安全措施

运维体系面临的问题

系统部分

  1. 系统多样性: windows, linux, freebsd各种操作系统,而且很多时候运行于上面的程序也会各不相同。

  2. 应用多样性: web前端, master db, slave db, ha以及各种不同应用程序。

  3. 人员更替频繁: 操作流程要做好。

网络部分

  1. 应用复杂: 每个项目都需要不同的架设方式

  2. 各种协议问题

安全体系面临的问题

  • 大量应用带来安全问题
  1. 发展过快导致安全断层。 设计初就要考虑好完整的系统架构,针对这个架构再加以实现安全规范,同时安全人员需要对程序代码进行安全审查。
  2. 重实现,忽视安全。对于功能的实现不能光停留在实现的层次上,而需要考虑系统的可扩展性。而不是只是为了实现基本功能,而到时候要修改程序就十分麻烦了再。
  • 人员安全意识不足
  1. 安全需要普及意识。这个普及不光是意识上,而且制度上也要建立起来的。
  • 攻击方式多样
  1. 对安全人员要求更高。攻击方式已经不光是XSS,DDOS,更有注入以及CRSE等等。而这些都是需要安全人员自己学习的。

运维体系

  • 标准化
  1. 系统安装:系统安装需要有标准化文档,标准化文档也可以进行更新。
  2. 系统配置:对于不同的需求需要有不同的系统配置文档。
  3. 应用编译:这个一般就是针对XNIX系统。
  • 网络横向划分
    1. 保证足够的纵深。
  • 网络纵深划分
  1. 根据应用划分网络,隔绝不同的应用服务器,不用各个不同的系统之间调用相同的数据。
  2. 根据需要划分网络,监控和前台以及数据库之间要互相分离开来。