前言

又到1年的总结时，从12年毕业开始工作到现在已经9年了，越发发现工作和生活越来越没有分界线，工作中融入生活、生活中融入工作，不知道是工作性质问题还是每个工作到了这个年限都有这样，所以今年的章节也不在沿用之前的生活、工作大章节划分，以重点事项叙述，下面开始进入正题。

2020大总结

Work From Home

今年因为这突如其来的疫情，体验了大半年的在家办公，但宅在家里的几个月也属实难受，偶尔出去采购虽开心到起飞，但也是全副武装，好在ZF的强管控力度，很快全面恢复了正常，并且疫情返工后，之家的上班时间从固定的9点变成了9-10点的弹性制，个人生物钟回归从前，简直不能再完美，整个人的精神状态也焕然一新。

经过1年多的运维相关业务梳理、运维自动化系统建设，现在终于要开始再搞点新鲜的东西了，这次准备将混沌工程体系引入现在的公司，基于开源的chaosblade，建设之家混沌工程实践体系，通过可控混沌工程实验，探索并提升之家系统韧性。

立项背景：
随着微服务、云原生相关技术的发展，分布式系统已经运行在之家各处，但因此也带来了复杂度急剧上升、故障发生难以预测后果、难以避免与验证等挑战，而混沌工程正是通过故障注入等方式为切入点，帮助解决以上问题

痛点分析：
1、在生产环境中实际运行分布式系统，难免会有各种不可预料的突发事件发生，云原生的发展，不断推进着微服务的进一步解耦，海量的数据与用户规模也带来了基础设施的大规模分布式演进，分布式系统天生有着各种相互依赖，可以出错的地方数不胜数，处理不好就会导致业务受损，或者是其他各种无法预期的异常行为
2、在复杂的分布式系统中，无法阻止这些故障的发生，我们应该致力于在这些异常行为被触发之前，尽可能多地识别风险，针对性地进行加固、防范，从而避免故障发生时所带来的严重后果

前言

写总结的第10个年头，今年在模式化的生活中还遇到一个崎岖的坎，工作上也进入了第二职场至今快6个月了，下面就开始今年的总结吧。

2018大总结

生活志

今年上半年的生活轨迹跟去年一致，家-公司，公司-家，生活半径5公里，下半年由于工作的原因半径扩充10公里，也终于进城了，但今年依然没有找到特别感兴趣的兴趣爱好，今年的唯一一个变化就是全家出去吃饭的次数多了，带娃逛奥特莱斯的时间多了。

运维故障的分析在每个运维团队都是一个重点的事项，以史明鉴，尤其对于未经历过该故障新加入团队的成员起到很关键的作用，这一版故障管理系统并非首版，为什么需要再上一版这里做一下简要说明。

• 1、流程上的变化，目前企业微信通知已经取代短信变为主流，企业微信方式的通知在加大而增加了信息传递量的同时可以允许运维进行反馈式交互，可以更全面全面的记录一个报警或者故障的完整处理流程。
• 2、故障标签的管理，在上一版本中标签的管理是固定式的，当进行标签的变化时需要开发团队配合对系统进行升级，极大的限制了运维团队对于故障管理的灵活性
• 3、故障描述，大部分的运维人员对于一个故障的总结能力还是比较弱的，以大段的文字形描述一个故障从发生到发现到结束往往让人听的晕头转向
• 4、绩效，太多的绩效计算以及规则在使用几个月以后就让所有人搞不明白了，及时连产品设计人员都不能很明确的解释绩效的算法

基于以上的痛点，我们进行了新一版本的系统设计。

早在两年前就计划对现在的内网管理系统进行一次全面的升级了，由于种种原因一直在搁置，从年初开始本系统终于有了实质性的进展，本系统的第一期项目也完成了需求、开发并正式落地投入使用，这套系统运用Linux下的rt_table、iproute、iprule、iptables、ipset、tc、netfilter-layer7、dpdk等技术实现支持多出口线路切换、IP分配、限速（白名单）、互通、流量统计等一系列功能，并通过SpringBoot+Vue打造的一套Web前端进行可视化管理。下面来讲一下这款产品的设计，这套设计基于前篇文章 系统需求分析管理[指导规范] 设计。

定义

本指导规范适用于存在用户界面的系统需求分析及设计，对业务部门所给予的需求，利用技术及工具进行业务规则、业务范围、业务流程等方面分析，并产出开发人员可以理解的需求分析产出。

需求分析流程

前言

不知不觉总结已经写了9年，而且人也马上奔3了，日子感觉越过越快，一眨眼的功夫1年过去了，为留下自己每年的轨迹总结还得继续。去年抢注了我本博客域名的那畜生竟然还又给续费了，本来想到期转回来了，再等1年，我看他能续费几年。

2018大总结

生活志

整理自己这一年的生活，发现轨迹越来越模式化，基本上就是家-公司，公司-家，生活半径5公里，以往需要出门办的事也几乎都可以网上解决，也就偶尔商场看个电影，逛逛宜家，滑个雪，工作也基本上不出差，还真没有别的什么了，其他时间就宅在家里，没事刷刷美团看看有没有什么新鲜的娱乐（但还真没发现啥）。全年空闲时外出时间不超过10%，当然这也是有原因的，上半年老婆怀孕，得宅在家里，下半年儿子出生，得宅在家里。翻了一遍手机的照片，讲讲下面几个事情吧。

方案概述

本技术方案为基于kubernetes(下文简称K8S)为核心的持续部署(下文简称CD)方案，可以满足开发方的程序级日志查看分析，运维方的快速扩容与日常运维分析，并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升，在不降低服务可靠性的前提下降低资源使用成本。

使用场景分析

本方案适用于以Tomcat为容器的JavaWeb项目的持续部署过程，在K8S方案中，所有的Node节点均采用统一配置，根据业务环境的需求进行节点数量的控制

技术架构与选型

为加固当前服务器管理的安全性，解决现阶段多个入口的登录方式，推进资产统一使用堡垒机（JumperServer）进行管理

JMS部署架构

基于JMSV1.0修订部分

• 修订JMS节点相关数据结构，加快JMSZtree的生成速度(20s->2s)
• 阉割web terminal(取消掉此功能)
• 阉割资产信息、节点信息的编辑操作(每三分钟与中心应用进行同步)
• 取消每次程序启动执行的资产信息检测，将定期检测修订为每2小时一次
• 阉割coco的分组显示功能(分组无法有层级结构，遂取消，建议使用搜索)
• coco只允许使用密钥登录(不允许使用密码登录)
• 修复重置公钥BUG(管理员重置公钥时不生效BUG修复)
• 默认ssh连接超时修订为30s，修复不支持10s以上超时显示BUG(目前最多支持两位数)
• 禁止删除ROOT帐号(安全性考虑防止用户误删ROOT帐号)

前言

鉴于去年的总结拖延症问题，今年的总结整理的时间还是比较早的，回顾今年的一整年的生活及工作，各方面都在有条不紊的进步，但整体来说我自我感觉对本年度并不是特别满意，其实这也是一个矛盾的体现，生活、工作上事事顺利是努力的目标，但向这个目标努力也越发感到危机，今年比较郁闷的是原先的Blog域名忘记续费了，然后被抢注了，还挂上了六*彩，郁闷！等它到期再买回来吧。好了，感慨就发到这了，下面开始回顾2017年度的大事件吧！

2017大总结

比较惭愧，“2016大总结，2017大畅想”中没有畅想！今年好好畅想。

生活篇

阅读

今年没有读几本书，自己的阅读能力这几年在逐年下降，现在越来越不愿意进行完整化的阅读了，但碎片化的阅读又非常没有营养，今年要立志改善！尽量避免碎片化阅读，像什么刷今日头条、脉脉、微博等今年要一刀切拒绝！阅读的目标转向得到、即刻、知乎、豆瓣。并且今年重启豆瓣主页，在阅读的书籍方面，仍然以技术方向为主（偏技术底层），管理、民科为辅的阅读。