《Web Operations:Keeping the Data on Time》笔记二
第7章 复杂系统是如何失败的
观点：
复杂系统本质上都是灾难系统
复杂系统都背重重地然而也是成功的防护着
灾难要求多点失效，单点失效是不够的
复杂系统包含潜藏在其中的权限的变化混合物
复杂系统以降级模式运行，这是因为系统包含着了很多冗余
灾难随时都会发生
事后归结为“根本原因”是根本错误的，发生明显失效要求多个缺陷的组合，所以不存在鼓励的事故原因
事后人事对人类行为的事后评估存在偏见
人类操作员有双重角色，作为生产者以及作为失效的防护者
所有操作者的行动都是赌博，发生事故之后，明显的失效看起来是无法避免的
最困难的行动解决了所有的模糊性
人类操作者是复杂系统的可调整因素
复杂系统中，人类专门知识处于不断变化中
变化会引入新的是想哦啊
原因观点显示了对未来事件的有效防护
安全是系统的特性，不是系统的组件
持续创造安全的是人
无事故的运维需要经历事故的历练
特别针对Web运维而言：
了解系统失效很困难
了解那部分失效很困难
有意义的响应会呗延迟
沟通产生紧张，而脾气会冒火
维护会成为新的失效的主要源头
从备份中恢复本省就由困难，而且还有潜在的危险
创建测试过程，一线人员用来验证系统的状态
对运维系统进行例行的每日管理
控制维护
定期对性能进行评估
要成为（独一无二的）客户
第8章社区管理与web运维
运行一个大型且广为人知的网站，意味着湖有大批依赖于网站快速而稳定的服务，并且针对这种服务的依赖是无时间限制的，这些人会形成一个社区。通常认为Web运维是一个纯粹的技术领域，大体而言，也确实如此，不过，假如这种非常技术化的服务影响了人们的生活，维护工程就必须将人的因素考虑进去，这酒需要大量的协作和沟通。失效依旧对失效的响应是人们最关注的。
社区管理如何和技术团队合作？
首先关于工作：
作为编辑和管理者，社区管理员需要知道如何把有趣的东西推到前面去，一个好的社区管理员应该了解推动事情进展的动力。
社区管理和技术支持之间的关系：
web是个巨大的混沌球，对于社区网站，发生问题时，尽可能向用户透明是很重要的。解决问题的人要在场，就问题的进展情况保持沟通，发生问题时运维人员或者开发人员应该和社区管理沟通。
第9章 处理非预期的访问量激增
分析架构，找到原因
先用缓存定制，如果发生缓存踩踏，用代理去解决
CDN是解决静态文件带宽问题的救命稻草。
第10章 开发者与运维者的协调和合作
传统上，开发团队和运维团队有不同的目标,软件开发团队需要安静的房间，长时间不受打扰，运维团队需要快速反应，传统意义上，开发人员没有动力将网站做得易于维护，开发人员交互的代码通常是一个黑盒子，一旦发生意外，运维团队没有办法去修复问题。发布的文档也是拼凑的。
成功的互联网公司正在尝试用另外的办法组织团队，少数公司消除了两个团队之间的区别。
先从部署来探讨：
1.部署，对于每个团队来说，发布过程中都有这样一个点，在这个点上，一段代码将不有写这段代码的开发人员用用，而是转由一个更为广泛的群体所支持，这个移交点时运维团队和开发团队之间最为重要的交互点，但多数组织都没怎么在意。以合适的方法进行移交，则不同团队之间就能更好的共同工作，但是改变过程是困难的。
在大多数组织中，代码在进入生产环境之间要经过多次移交（代码复审，测试，QA，发布管理），随着代码基变得越来越复杂，以及开发团队的不断增长，与部署庸官的宕机和集成缺陷会越来越频繁，随着过程的越来越复杂，准备部署的过程也越来越长，不频繁的更新，会影响产品的受欢迎程度。
因此小更新非常重要，但是小更新也由自己的问题，只有遵守下面三条规则的情况下，频繁的小更新才起作用：
构建与部署系统必须能够完全重复且自动地工作
具有几近完美的预演环境
部署必须尽可能的快，理想情况是小于5分钟，
来自Flickr的部署经验：
部署基于系统去实现，系统基于web，包含两个按钮：预演和部署，预演从源代码控制系统中检出最新的版本，对其进行构建，然后将结果代码推入预演服务器；部署将当前处于预演的状态的代码推入生产环境，然后执行一些部署后的清理工作，将系统做成web，保证了所有的构建都在同一的环境中进行，不会由于工横工作环境的微笑配置差异而引起任何错误，构建是自动化的，因此开发人员可以自己做代码推入。
共享、开放的基础架构，往往开发人员和运维工程人员分为不同的小组，你会发现基础建构也一分为二的。多数情况下，这样做是出于实目的的，但是为了建立信任，你需要让工作变得透明。
遵循下面三个简单步骤，你可以改进这种局面
首先一个页面，上面放上所有工具的链接，让每个团队中的人都可以编辑，鼓励每个人都把他们的开发或发现的工具放上去。
其次确保你的团结有套路他们使用的工具，特别是工具帮助他们解决的问题。
最后是引进一种策略，给予每个人所有系统只收只读的访问权限。
将运维和开发分开的一个最常见的误识是认为只有运维团队的成员才可以修正生产环境的问题，但是需要随叫随到的开发人员来解决问题。
本文为Lokie.Wang原创文章,转载无需和我联系,但请注明来自lokie博客http://lokie.wang
- 最新评论
- 总共0条评论
