工作中的思考

其实我个人挺懒的，虽然在JDJR这两年不论是在技术还是思路上我都学到很多东西，而且在别人说到相关的东西也立马能够心领神会(原谅前面有点夸张)，but，我仍然不能够将自己熟悉的技术理论以及一些运维理念流程之类的东西很自然的结合到一个整体。我总结了下，原因是太懒，没有将平时的所学所感所悟进行系统性梳理和结合。然而，任何事物，如果我们只是单纯的去执行，不去思考深层次的东西或者站在工程学角度去系统思考的话，那么最终我们也将会遇到瓶颈，而作为一个运维人来说，我觉得这点尤其重要。So,即使比coding难很多，我还是打算好好梳理下。

1.业务机房迁移

来PE(应用运维)团队接触的第一个大项目可以算是大规模业务项目机房迁移了。背景大概是由于网络架构改造，当时所有金融的在线业务都需要平滑迁移到另外一个机房。(没办法，赶上了移动互联网的大浪潮，业务发展也是节节升高，考虑到未来的发展，网络架构调整实在是一个明智的规划)。业务机房迁移其实说起来很好理解，简单点说就是将业务迁移到另外一个机房的应用服务器上去，然而操作起来并不是那么简单的，至于多复杂，很多辛酸泪就不说了，反正整个迁移从项目开始到最终结束大概经历了一年半的时间，当然这些不是重点，重点是在这整个迁移过程中我学到了哪些，作为一个运维人(Opser)应该如何去支持并帮助应用业务项目实现价值。

• 熟悉运维架构
• 
  这点其实是很重要的，因为你需要掌握公司体系内部的整个运维架构是怎样的，用的基础工具以及流程是怎样的(从域名解析到vip到后端的软负载甚至到一些基础软件设施)，这样才能站在运维的角度去帮助业务研发进行上线部署以及后期运营。当然至于运维架构本身是否合理可靠，可以暂时不去考虑，放给更加专业的人去考量。
• 
  
• 熟悉业务架构
• 
  在整个业务迁移初期其实挺蛋疼的，因为对业务架构不是很熟悉，不清楚每个业务系统的底层依赖以及周围系统的调用依赖(可能因为人员流动，相应的研发也不一定特别清楚)，还有部分奇怪的项目会写死ip去调用，或者去写死hosts。这些都给当时的迁移造成很大的麻烦。后期，摸清套路后大家就都没有那么难受了。所以作为PE(应用运维)来说，熟悉业务架构会非常的重要，这样可以结合底层运维架构以及业务架构对业务进行建议改造。说实话，整个迁移完成后对金融大部分的业务架构都比较熟悉，这也为后期的维护提供了很多的便利。
• 
  
• 引导业务研发按照标准化流程走
• 
  迁移的另外一个好处就是可以重新梳理并统一部署标准化，在历史的应用部署中往往会有目录标准不统一，或者随意修改系统文件之类的变更，迁移的过程也是梳理并统一标准化的过程。
• 
  
• 了解业务会使用到相关技术
• 
  毕竟我们这个工种也是技术序列，掌握运维相关技术架构是很重要的，但是适当了解并熟悉业务的相关技术也是必要的，比如说JVM调优，Tomcat配置优化等等，这样才能做到业务研发与运维之间的正向反馈，互惠互利，并最终快速实现业务价值
• 
  
  

2.分布式k/v存储系统运维

基本上业务迁移项目快完结的时候就开始接手公司内部的分布式键/值存储系统(主要是当时待迁移的业务属于非标应用，研发部门迁移成本比较大，况且当时我们已经把迁移需要的准备工作都已完成，如果继续将大部分精力投入该项目，时间成本以及精力成本将会很大)。公司上一代分布式键/值存储系统是基于redis2.8使用一致性hash算法构建的k/v存储系统，在维护期间深入学习了redis相关的知识，包括各种使用场景的使用方式，troubleshooting，甚至底层系统的相关内核调优等工作(很遗憾的是redis的源码没有看太多)。好的架构总是不断演进而来的，redis3.0以前的版本是不支持集群模式的，但是业界总是能搞出一些工具系统去支撑业务的高吞吐、高并发请求，实现分布式存储，比如由Twtter开源的Twemproxy,豌豆荚开源Codis,搜狐视频开源的CacheCloud。当然啦，使用外部代理的方式总会有些许问题，比如通过代理后的性能问题，数据一致性的问题等等(感觉自己说了一句废话，因为没有完美的解决方案，总会有些许问题的)，So,redis3+之后的版本增加了集群模式(相当于在存储层面多了一层slot用来进行数据管理，使用Raft协议来保持一致性)，而公司内部正好有大神在做基于redis3+ 的分布式弹性k/v存储。由于老系统在金融业务使用过程中的种种弊端，最终通过综合对比决定将目前业务在使用的redis集群迁移到内部大神们构建的基于redis 3+的分布式弹性k/v存储系统R2M上。(其实当时个人考虑最多的是运维成本，毕竟之前那种代理方式运维工具太不友好了，而redis cluster中内部集成了运维管理工具，再加上当时对比redis代理集群模式和cluster集群模式的性能测试并没有发现什么差异，就向领导申请将业务使用的redis迁移新集群平台上，主要是想在精神上有满满的支持)。紧接着就是持续了大半年的redis迁移，redis迁移不像业务应用迁移那样，毕竟是用来存数据用的，秒级的失误也是可能导致业务可用率下降的，当时迁移也是经常在半夜里进行，不过后来随着工具的完善以及经验的丰富，迁移进度和迁移时间也都很随意了(迁移这件事肯定不能随意)，只要研发确定好时间随时可以迁移，截至去年618(全职维护分布式k/v存储R2M的最后一个月)，整个R2M平台已经将大部分老系统的业务迁移过来，并承载了金融大部分的业务系统。在维护整个分布式k/v存储系统期间其实也是我成长最快的阶段，因为从开始的业务应用项目的维护到基础平台项目的维护过程中需要转变和学习的东西还是蛮多的，个人总结大概以下几点：

• 熟悉底层的基础架构技术
• 
  做基础架构平台的运维一定得对底层技术细节有一个深入的了解，虽然我们有专业的redis研究和平台开发人员，但是作为开发和运维的纽带角色－PE，我们必须对相关的技术细节有深入的了解，否则也不能为业务开发提供最快最高效的业务支持。
• 
  
• 善于沟通
• 
  可能作为IT人大部分都是不善于沟通的，但是运维这个角色必须要学会与不同的人沟通(原谅我其实有些许的沟通障碍，不过在慢慢尝试)，因为这样你才能说服业务方去按照你的架构你的计划去实施，从而实现让运维和研发在某一个点上达成一致。
• 
  
• 熟悉业务
• 
  还是业务，如果说在在前期迁移业务应用的时候需要熟悉业务架构的话，那这个时候应该就是要熟悉业务细节了。业务研发在开发初期并不会考虑太多使用上的细节，然而我们需要考虑到整个系统的可用性，可靠性以及吞吐率等。比如在初期，总会有不明真相的业务研发在使用redis的时候会使用keys命令而导致redis堵塞，进而造成业务系统的高延迟，又或者存放一些本可以丢弃的数据，一直占用物理资源。这些问题后期我们都会和业务去进行深入谈判，并给出相应的解决方案，使之对业务系统进行改造。
• 
  
  

3.Docker在业务场景中的使用

去年618结束之后，分布式k/v存储系统R2M基本上已经可以平稳支撑各个业务系统，当然R2M平台未来还是需要不断改进的，包括业务支持，事实证明这大半年搞R2M那帮大神和当时我交接运维的那些同事都是相当牛逼的，我离开之后就去搞docker了，而他们在精细化运营的道路上一直探索着，并且稳定度过11.11和各个大促。

我开始搞docker是一个很机缘巧合的过程，618过后正值有个业务系统想尝试使用docker的特性进行构建业务系统，虽然当时docker也炒的比较火，但是对于我们内部来说还是比较未知，比较新的一个东西。之后我便接下来这个项目去研究docker相关的技术，不可不说的是docker用于生产环境还是蛮复杂的，因为里面需要考虑到很多相关的东西，包括底层操作系统，网络，docker的存储驱动选型，数据卷存储，容器的编排调度以及生命周期管理，监控以及日志等等。另外一个要说的是，docker真的有多的优势，在使用docker的同时一定要想清楚要解决什么问题，结合业务场景去选择docker的某一种技术选型，以业务支撑的角度去做docker选型而不是以docker技术本身去做技术选型。幸而那个业务比较简单规模也比较小，基本上两个月就上线了(虽然后期也不断出现一些问题，但总是会有办法去解决改造的)，后期就是正常的业务升级以及维护了。由于该项目比较特殊，当时无法使用我们生产的部署系统进行快速的变更管理，初期靠人工进行维护变更。然而后期在不断的学习中引入的各种自动化工具进行变更管理。在负责整个业务项目中，相当于是从底层操作系统，到最上层的应用我都全部接手了一遍，说实话从底层完整的支撑一个业务系统让我学到并且思考了更多的东西。

• 项目需求梳理
• 
  向上需要梳理业务系统的需求，调研相关的技术细节；向下需要梳理底层技术细节包括操纵系统版本，基础网络配置需求，存储相关需求等
• 
  
• 部署规划
• 
  部署生产环境就一定要标准化先行，这样才能为之后的流程化，自动化做好铺垫，包括应用代码放置目录，基础软件包放置路径，日志以及数据目录等
• 
  
• 变更管理
• 
  项目初期使用人工进行多实例部署变更，但这种方式是很容易造成标准化缺失问题，后来尝试在项目环境使用Ansible进行统一的变更管理，即使未来需要扩展docker的基本环境，也依然可以在很快时间内进行统一的配置变更管理
• 
  
• 监控和报警
• 
  俗话说的好：无监控不线上，由于使用的是应用容器化，在监控方面，还是很受挑战的，当时调研了很久，最终选择了Telegraf+Influxdb+Grafana这一套进行基础监控(遗憾的是性能监控目前还没有找到合适方案)，报警由于也是比较特殊的点，临时写了小程序在服务器上进行日志分析，然后报警到邮箱。但其实在监控和报警这块是可以做很多事的，业务场景比较单一，当前的解决方案还是可以满足目前的需求的。
• 
  
• 日志
• 
  日志也是docker容器使用中需要解决的一个问题，该项目中暂时没有进行日志相关的处理(心寒啊，没有来得及去研究)。docker容器的日志方案一些官方的建议是可以使用log-dirver将容器的标准输出数据流直接发送到远端，然后进行日志存储以及分析。官方其实是支持很多中日志驱动的：json-file,syslog,journald,gelf,fluentd,splunk等。虽然没有在业务中尝试这样使用，但是在内部的docker镜像仓库harbor的使用过程中各个组件容器使用了syslog将其他容器的日志进行统一的收集和处理，所以后期日志这块会去尝试几种解决方案
• 
  
  

4.Docker相关的技术研究

现在，我依然负责部分的业务运维，上面那个docker项目我也依然在维护支持，但是目前更多的是研究docker相关的技术，也有其他团队在一起努力做这件事，最终实现基于docker的CI/CD整个流程、基于docker的标准化应用支持(包括编排调度)、企业内部的多功能镜像仓库(App Store)。关于目前docker相关的一些感悟和思考，实在是太多了，也许等过一段时间再总结起来收获会更多，因为整个过程中需要考虑和关注的点更多，我还在继续前行，继续努力探索，期待未来分享的那天。

工作中的思考

其实我个人挺懒的，虽然在JDJR这两年不论是在技术还是思路上我都学到很多东西，而且在别人说到相关的东西也立马能够心领神会(原谅前面有点夸张)，but，我仍然不能够将自己熟悉的技术理论以及一些运维理念流程之类的东西很自然的结合到一个整体。我总结了下，原因是太懒，没有将平时的所学所感所悟进行系统性梳理和结合。然而，任何事物，如果我们只是单纯的去执行，不去思考深层次的东西或者站在工程学角度去系统思考的话，那么最终我们也将会遇到瓶颈，而作为一个运维人来说，我觉得这点尤其重要。So,即使比coding难很多，我还是打算好好梳理下。

1.业务机房迁移

来PE(应用运维)团队接触的第一个大项目可以算是大规模业务项目机房迁移了。背景大概是由于网络架构改造，当时所有金融的在线业务都需要平滑迁移到另外一个机房。(没办法，赶上了移动互联网的大浪潮，业务发展也是节节升高，考虑到未来的发展，网络架构调整实在是一个明智的规划)。业务机房迁移其实说起来很好理解，简单点说就是将业务迁移到另外一个机房的应用服务器上去，然而操作起来并不是那么简单的，至于多复杂，很多辛酸泪就不说了，反正整个迁移从项目开始到最终结束大概经历了一年半的时间，当然这些不是重点，重点是在这整个迁移过程中我学到了哪些，作为一个运维人(Opser)应该如何去支持并帮助应用业务项目实现价值。

• 熟悉运维架构
• 
  这点其实是很重要的，因为你需要掌握公司体系内部的整个运维架构是怎样的，用的基础工具以及流程是怎样的(从域名解析到vip到后端的软负载甚至到一些基础软件设施)，这样才能站在运维的角度去帮助业务研发进行上线部署以及后期运营。当然至于运维架构本身是否合理可靠，可以暂时不去考虑，放给更加专业的人去考量。
• 
  
• 熟悉业务架构
• 
  在整个业务迁移初期其实挺蛋疼的，因为对业务架构不是很熟悉，不清楚每个业务系统的底层依赖以及周围系统的调用依赖(可能因为人员流动，相应的研发也不一定特别清楚)，还有部分奇怪的项目会写死ip去调用，或者去写死hosts。这些都给当时的迁移造成很大的麻烦。后期，摸清套路后大家就都没有那么难受了。所以作为PE(应用运维)来说，熟悉业务架构会非常的重要，这样可以结合底层运维架构以及业务架构对业务进行建议改造。说实话，整个迁移完成后对金融大部分的业务架构都比较熟悉，这也为后期的维护提供了很多的便利。
• 
  
• 引导业务研发按照标准化流程走
• 
  迁移的另外一个好处就是可以重新梳理并统一部署标准化，在历史的应用部署中往往会有目录标准不统一，或者随意修改系统文件之类的变更，迁移的过程也是梳理并统一标准化的过程。
• 
  
• 了解业务会使用到相关技术
• 
  毕竟我们这个工种也是技术序列，掌握运维相关技术架构是很重要的，但是适当了解并熟悉业务的相关技术也是必要的，比如说JVM调优，Tomcat配置优化等等，这样才能做到业务研发与运维之间的正向反馈，互惠互利，并最终快速实现业务价值
• 
  
  

2.分布式k/v存储系统运维

基本上业务迁移项目快完结的时候就开始接手公司内部的分布式键/值存储系统(主要是当时待迁移的业务属于非标应用，研发部门迁移成本比较大，况且当时我们已经把迁移需要的准备工作都已完成，如果继续将大部分精力投入该项目，时间成本以及精力成本将会很大)。公司上一代分布式键/值存储系统是基于redis2.8使用一致性hash算法构建的k/v存储系统，在维护期间深入学习了redis相关的知识，包括各种使用场景的使用方式，troubleshooting，甚至底层系统的相关内核调优等工作(很遗憾的是redis的源码没有看太多)。好的架构总是不断演进而来的，redis3.0以前的版本是不支持集群模式的，但是业界总是能搞出一些工具系统去支撑业务的高吞吐、高并发请求，实现分布式存储，比如由Twtter开源的Twemproxy,豌豆荚开源Codis,搜狐视频开源的CacheCloud。当然啦，使用外部代理的方式总会有些许问题，比如通过代理后的性能问题，数据一致性的问题等等(感觉自己说了一句废话，因为没有完美的解决方案，总会有些许问题的)，So,redis3+之后的版本增加了集群模式(相当于在存储层面多了一层slot用来进行数据管理，使用Raft协议来保持一致性)，而公司内部正好有大神在做基于redis3+ 的分布式弹性k/v存储。由于老系统在金融业务使用过程中的种种弊端，最终通过综合对比决定将目前业务在使用的redis集群迁移到内部大神们构建的基于redis 3+的分布式弹性k/v存储系统R2M上。(其实当时个人考虑最多的是运维成本，毕竟之前那种代理方式运维工具太不友好了，而redis cluster中内部集成了运维管理工具，再加上当时对比redis代理集群模式和cluster集群模式的性能测试并没有发现什么差异，就向领导申请将业务使用的redis迁移新集群平台上，主要是想在精神上有满满的支持)。紧接着就是持续了大半年的redis迁移，redis迁移不像业务应用迁移那样，毕竟是用来存数据用的，秒级的失误也是可能导致业务可用率下降的，当时迁移也是经常在半夜里进行，不过后来随着工具的完善以及经验的丰富，迁移进度和迁移时间也都很随意了(迁移这件事肯定不能随意)，只要研发确定好时间随时可以迁移，截至去年618(全职维护分布式k/v存储R2M的最后一个月)，整个R2M平台已经将大部分老系统的业务迁移过来，并承载了金融大部分的业务系统。在维护整个分布式k/v存储系统期间其实也是我成长最快的阶段，因为从开始的业务应用项目的维护到基础平台项目的维护过程中需要转变和学习的东西还是蛮多的，个人总结大概以下几点：

• 熟悉底层的基础架构技术
• 
  做基础架构平台的运维一定得对底层技术细节有一个深入的了解，虽然我们有专业的redis研究和平台开发人员，但是作为开发和运维的纽带角色－PE，我们必须对相关的技术细节有深入的了解，否则也不能为业务开发提供最快最高效的业务支持。
• 
  
• 善于沟通
• 
  可能作为IT人大部分都是不善于沟通的，但是运维这个角色必须要学会与不同的人沟通(原谅我其实有些许的沟通障碍，不过在慢慢尝试)，因为这样你才能说服业务方去按照你的架构你的计划去实施，从而实现让运维和研发在某一个点上达成一致。
• 
  
• 熟悉业务
• 
  还是业务，如果说在在前期迁移业务应用的时候需要熟悉业务架构的话，那这个时候应该就是要熟悉业务细节了。业务研发在开发初期并不会考虑太多使用上的细节，然而我们需要考虑到整个系统的可用性，可靠性以及吞吐率等。比如在初期，总会有不明真相的业务研发在使用redis的时候会使用keys命令而导致redis堵塞，进而造成业务系统的高延迟，又或者存放一些本可以丢弃的数据，一直占用物理资源。这些问题后期我们都会和业务去进行深入谈判，并给出相应的解决方案，使之对业务系统进行改造。
• 
  
  

3.Docker在业务场景中的使用

去年618结束之后，分布式k/v存储系统R2M基本上已经可以平稳支撑各个业务系统，当然R2M平台未来还是需要不断改进的，包括业务支持，事实证明这大半年搞R2M那帮大神和当时我交接运维的那些同事都是相当牛逼的，我离开之后就去搞docker了，而他们在精细化运营的道路上一直探索着，并且稳定度过11.11和各个大促。

我开始搞docker是一个很机缘巧合的过程，618过后正值有个业务系统想尝试使用docker的特性进行构建业务系统，虽然当时docker也炒的比较火，但是对于我们内部来说还是比较未知，比较新的一个东西。之后我便接下来这个项目去研究docker相关的技术，不可不说的是docker用于生产环境还是蛮复杂的，因为里面需要考虑到很多相关的东西，包括底层操作系统，网络，docker的存储驱动选型，数据卷存储，容器的编排调度以及生命周期管理，监控以及日志等等。另外一个要说的是，docker真的有多的优势，在使用docker的同时一定要想清楚要解决什么问题，结合业务场景去选择docker的某一种技术选型，以业务支撑的角度去做docker选型而不是以docker技术本身去做技术选型。幸而那个业务比较简单规模也比较小，基本上两个月就上线了(虽然后期也不断出现一些问题，但总是会有办法去解决改造的)，后期就是正常的业务升级以及维护了。由于该项目比较特殊，当时无法使用我们生产的部署系统进行快速的变更管理，初期靠人工进行维护变更。然而后期在不断的学习中引入的各种自动化工具进行变更管理。在负责整个业务项目中，相当于是从底层操作系统，到最上层的应用我都全部接手了一遍，说实话从底层完整的支撑一个业务系统让我学到并且思考了更多的东西。

• 项目需求梳理
• 
  向上需要梳理业务系统的需求，调研相关的技术细节；向下需要梳理底层技术细节包括操纵系统版本，基础网络配置需求，存储相关需求等
• 
  
• 部署规划
• 
  部署生产环境就一定要标准化先行，这样才能为之后的流程化，自动化做好铺垫，包括应用代码放置目录，基础软件包放置路径，日志以及数据目录等
• 
  
• 变更管理
• 
  项目初期使用人工进行多实例部署变更，但这种方式是很容易造成标准化缺失问题，后来尝试在项目环境使用Ansible进行统一的变更管理，即使未来需要扩展docker的基本环境，也依然可以在很快时间内进行统一的配置变更管理
• 
  
• 监控和报警
• 
  俗话说的好：无监控不线上，由于使用的是应用容器化，在监控方面，还是很受挑战的，当时调研了很久，最终选择了Telegraf+Influxdb+Grafana这一套进行基础监控(遗憾的是性能监控目前还没有找到合适方案)，报警由于也是比较特殊的点，临时写了小程序在服务器上进行日志分析，然后报警到邮箱。但其实在监控和报警这块是可以做很多事的，业务场景比较单一，当前的解决方案还是可以满足目前的需求的。
• 
  
• 日志
• 
  日志也是docker容器使用中需要解决的一个问题，该项目中暂时没有进行日志相关的处理(心寒啊，没有来得及去研究)。docker容器的日志方案一些官方的建议是可以使用log-dirver将容器的标准输出数据流直接发送到远端，然后进行日志存储以及分析。官方其实是支持很多中日志驱动的：json-file,syslog,journald,gelf,fluentd,splunk等。虽然没有在业务中尝试这样使用，但是在内部的docker镜像仓库harbor的使用过程中各个组件容器使用了syslog将其他容器的日志进行统一的收集和处理，所以后期日志这块会去尝试几种解决方案
• 
  
  

4.Docker相关的技术研究

现在，我依然负责部分的业务运维，上面那个docker项目我也依然在维护支持，但是目前更多的是研究docker相关的技术，也有其他团队在一起努力做这件事，最终实现基于docker的CI/CD整个流程、基于docker的标准化应用支持(包括编排调度)、企业内部的多功能镜像仓库(App Store)。关于目前docker相关的一些感悟和思考，实在是太多了，也许等过一段时间再总结起来收获会更多，因为整个过程中需要考虑和关注的点更多，我还在继续前行，继续努力探索，期待未来分享的那天。