前言

写总结的第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大畅想”中没有畅想！今年好好畅想。

生活篇

阅读

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

PandoraBox | 私密信息传递工具

基于非对称加密(RSA)的私密信息传递工具，数据由本地客户端进行加密、解密操作，密文通过网络进行传输，确保信息的安全性！
– Browse Website –

系统介绍

PandoraBox 由Server与Client两部分组成，Server使用Java SpringBoot编写，数据存储为Mysql，欢迎页面使用iview编写；Client使用C#编写，数据存储为sqlite，Client使用inno setup打包为安装包。且为了方便快速的信息发送，Server的数据结构内需要维护一套用户验证体系与用户组织结构，目前PandoraBox仅可发送文本信息。

经过一年的敏捷管理实践，基于PO制的敏捷模式在团队内效果良好，尤其是运维团队中，让运维的工作更具有节奏性且工作更为紧密。好的方面有很多，但是其中也发现很多的不足。

• 流程规范中众多的章节都是偏向于开发团队的，很多场景不适合运维团队
• 业务文档，技术文档拆分太细，不利于成员的理解与界限隔离
• 太过于依赖于会议进行沟通，导致开会前准备不足，会议效率过低

基于以上的问题，我们针对2017版的指导规范进行了需要重要的调整，合并运维项目管理与开发项目管理，规范更名在“敏捷迭代管理”，简化会议流程，追加需求实现规划阶段。

下面来看一下新版的规范