容器技术

1. kubernetes资料合集

http://special.csdncms.csdn.net/Kubernetes/?from=timeline&isappinstalled=0

要点: kubernetes 中文资料合集, 比较全.

2. docker技术介绍

链接: http://pan.baidu.com/s/1jGgrxzC 密码: jg4x

要点: 分享2篇介绍容器技术的 ppt, 一篇侧重于介绍容器技术的基本原理, 包括 cgroup, namespace 以及 docker 依赖的后端文件系统. 另一篇侧重介绍使用 docker 部署 mongodb 服务的经验. 有状态的服务要想达到快速部署的目的, 必须考虑状态的存储和恢复问题, 尤其是像数据库这种涉及大量数据的服务, 往往恢复服务的瓶颈就在于数据的同步上. 本文介绍依托于 mongodb 自动的数据迁移能力来实现数据的迁移. 另外还必须及时监控数据卷的各种异常, 比如数据卷不可访问, IO 速度变慢等问题, 本文介绍依赖于 DB 日志监控实现这一点.

3. etcd 2.1发布，可不宕机滚动升级

http://dockone.io/article/539#rd?sukey=fc78a68049a14bb2979f9a98b09780c256c59187018d4fdf5563b063fac0e6768e1ed4bafbd0b5480156cefc2c5639d0

要点: etcd 是一款定位和 zookeeper 相同的分布式 key-value 存储系统, 使用 raft 协议实现. ectd 2.1号称是 ectd 最稳定的版本, 同时实现了不宕机升级的功能.

4. 虚拟化技术的昨天、今天和明天

http://dockone.io/article/541

要点: 本文分别讨论Docker和OS虚拟化。然后解密作者深入分析数据之后发现的虚拟化领域正在和没有发生的事情。

服务化和资源管理技术

1. Docker背后的容器集群管理——从Borg到Kubernetes（二）

http://www.infoq.com/cn/articles/docker-container-cluster-management-part-02

要点: 本文重点阐述了 borg 论文中对资源控制的解读, 这也是 borg 论文的重点. 从文章中可以看出, borg 在如何提高资源利用率上下足了功夫, 不愧是google研发了近10年的"秘密武器".

2. WDT：多TCP链路的数据传输开源库

http://www.infoq.com/cn/news/2015/07/facebook-wdt

要点: facebook 开源的高效数据传输库, 在 facebook 的网络环境下可以达到近600Mb/s 的超高速传输.

3. Kubernetes v1.0新特性全角度解析

http://dockone.io/article/546

要点: 这是在 csdn container 群里的一个分享, 作者重点从负载均衡, 监控和 HA 解决方案上分享了 kubernetes 1.0的变化以及设计思路的转变.

服务调度技术

1. 使用异步 I/O 大大提高应用程序的性能

http://mp.weixin.qq.com/s?__biz=MzAwNjMxNjQzNA==&mid=208035935&idx=1&sn=017c60ae525c7696658e1623428b6b99&key=0acd51d81cb052bc9201f541ecff130d1d20c58c18f7e3a38944ecaad767ec5b02d9afa449255d35bb622b2e9a39d431&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=ErTapDTloYaYbXFd8m30cljMvomMo0Y%2Bp1QfvsTXlqdQ%2B3DDFn8JCr43f52wANva

要点: 本文介绍了 linux 的几种 IO 模型, 然后详细介绍了 aio 的使用方法和基本原理.

2. 七牛是如何搞定每天500亿条日志的

http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=211136387&idx=1&sn=b861d00ae41f993ee15e3fe9f745053f&key=0acd51d81cb052bc95ecbcfa63187eef872303c726e5eca6f8a3cc578ad1709eb3a2c9790319c7e724c9810bf0fc74d2&ascene=0&uin=ODI4MjczOTAx&devicetype=iMac+MacBookAir6%2C2+OSX+OSX+10.10.2+build(14C109)&version=11020012&pass_ticket=WqZgPuSJFtstSTwv1DTtqOJsx7rRVj65YNUC7JgZoL5CrhjBIDaIc4qd3bDT%2FRc%2B#wechat_redirect

要点: 本文介绍了七牛的日志收集, 传输和分析架构, 数据收集端是自己开发的 agent, 数据传输使用 kafka和 flume, 数据分析实时计算使用 spark streaming, 离线分析使用 mapreduce. 总共使用了8台机器, 抗80w TPS.

DevOps 技术

1. 应该对什么告警?

http://segmentfault.com/a/1190000003021919

要点: 告警是大家非常熟悉的东西了, 我们线上配置了无数的告警, 每天可以收到无数的告警邮件. 但是经常听到 op 抱怨, 线上告警太多而无法及时处理的问题, 那么应该如何设置告警才能最大程度的帮助我们及时发现并定位问题呢? 本文作者提出了如何有效的设置告警的三个原则: 系统是否在持续完成其设定的工作, 用户体验是否好以及问题或者瓶颈在哪里, 并且针对这些原则给出了设置告警的案例

2. Google SRE：运维还能如此高逼格？

http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=206883730&idx=1&sn=0c4ee925827cd29c8c36f4abab563540&scene=1&key=0acd51d81cb052bc5da1caf1f987a5dbc3b08e18b06b65e77ffd25d9d3ee2f621436d98cb7b0211898bc4c1d05f1b490&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=FNecT73%2Fn06dlrO2YmcQXH2L3NnbgByTAtu3nbjZomwU8T%2FxZ6f13a4Ou84pcSDS

要点:  这是一篇对原 google 工程师的访谈, 文章中描述了 google 的所谓 op 的工作职能. 看完后发现 google 是没有服务的专职 op 的, 所有服务的开发, 测试, 部署都是 SWE 完成的(SWE 包括 rd 和 qa), 这得益于 google 强大的基础架构. google 只有 SRE, 而且即使 SRE 也从来不接触物理机. 从文章中推断 SRE都是非常有经验的工程师组成的, 在性能优化和服务稳定性方面拥有非常丰富的经验. 什么时候我们也能达到这样的水平呢?

3. 腾讯蓝鲸核心功能图文详解

http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=206891916&idx=1&sn=76b09bc9622f3cc3ee692a54983ecac0

要点: 前面我也分享过腾讯蓝鲸系统的介绍文章, 这篇文章是一个补充, 重点阐述蓝鲸系统的故障自动恢复, 游戏无人值守自动开区, 自动发布变更, 运维使用大数据辅助运营等问题.

4. 可视化持续部署系统的设计与实现

https://mp.weixin.qq.com/s?__biz=MzA4NjAzMjEyOA==&mid=206038157&idx=1&sn=e01ad6904d60921b7005eccdb42192f2&key=0acd51d81cb052bc1937e95850e0a9f6987d7e914db9fbf7b0d0cfce0aafc8e988ec8b01931cc4b699dc8faae7d0bf6d&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=FNecT73%2Fn06dlrO2YmcQXH2L3NnbgByTAtu3nbjZomwU8T%2FxZ6f13a4Ou84pcSDS

要点: 持续部署系统我们其实不陌生, 原来的 beehive+863系统就可以看做是一个持续部署系统, 只不过我们在可视化方面做的比较弱. 和文章中介绍的持续部署系统不同, 对于配置管理这块, 我们是和程序打包在一起的, 每次配置变更都不方便, 我觉得863也应该把配置变更单独管理起来, 提供一个环境和配置的一一映射表, 根据环境生成对应的配置, 当然需要提供平台, 由 rd 来维护这个映射表.

5. 国内最大的游戏大佬如何开展运维实践？

http://mp.weixin.qq.com/s?__biz=MzAxNDU2MTU5MA==&mid=208213981&idx=1&sn=d7f5e0137fd4fa79ba9361b4027a57f7&scene=1&key=0acd51d81cb052bcfc6e6abb3635d492a4505f74028a7fedc38b4178ed014c84abac0b67e80b75396b83f410e99e2865&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=6X6XaP05Q6GT38M0DRLejECVKvZrTmXDwbALwDetuyC524aeRunbHf%2F1Bf6jMEpD

要点: 本文介绍了腾讯游戏运维的"四化"演化过程, "四化"即"标准化", "自动化", "服务化", "产品化". 在演化过程中, 按照职责的特点, 分成了操作运维, 开发运维和规划运维三个角色. 操作运维重点在操作原子化方面, 就是把很多有差异同时又有很多相同点的工作,拆分成一个一个原子化工. 开发运维重点在于实现这些原子化工具的页面化, 实现可视化运维. 规划运维的职责在于去规划我的这些操作场景有哪些？我的需求有哪些？把这些场景分装起来，场景分装之后其实就是把我们的这些流程，把所有的运维操作流程，把每一步骤流程化，分装之后，对于我们后面的操作运维来说，就可以固化的进行工具的操作。这和 beehive Job Engine 的思路是类似的, 我们希望 beehive Job Engine 首先实现原子化的 job 级接口的封装, 然后通过流程引擎把这些原子化的 job 级接口串联起来满足业务的需求.

工具集合

1. Web Service 性能测试工具比较

https://testerhome.com/topics/3003

要点: 本文介绍了几种常见的 web 服务性能测试工具, 大家可以尝试.

2. 28个Unix/Linux的命令行神器

http://mp.weixin.qq.com/s?__biz=MzAwNjMxNjQzNA==&mid=208098099&idx=1&sn=438db0addcf31604def97f084d8aafad&scene=1&key=0acd51d81cb052bc91d1cc313c7e525850dbd466e2bc7b701baf6917e31d409a445a9036156e0e5c83c7871347fa18a8&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=6X6XaP05Q6GT38M0DRLejECVKvZrTmXDwbALwDetuyC524aeRunbHf%2F1Bf6jMEpD

要点: 一些常用的命令, 没什么特别可介绍的, 如果觉得好用就用吧.

3. Linux mkdir、tar 和 kill 命令的 4 个有用小技巧

https://linux.cn/article-5863-1.html

要点: 这些应该是大家平时用的最多的命令了. 文章中介绍了平时的工作场景中, 需要两步或者三步的操作转化为一步的小技巧来提升效率. 我们可能从小就被教育要勤奋, 在 codereview 时我也见过很多同学非常"勤奋"的重复编写很多功能非常类似的代码, 作为工程师, 有时候我们需要"懒"一点, 能一步完成就不用两步(当然要保证逻辑清晰), 重复的逻辑尽量抽象成函数或者类来统一实现.