1.1 工作感悟

### 我的核心价值观（YD）： ##### 所有事以降本增效为目标 ``` 如果你做的工作即不降本，又不增效，那一定会被拒绝，连提都别提 ``` ##### 工作目标：让公司不需要我 ``` 运维工作不需要运维，才能证明个人的价值 ``` ##### 必须有知识库 ``` 建立完整的知识库，让运维信息不再因为人员变动而丢失 ``` ##### 必须有产出物 ``` 做好运维信息汇总，密码管理，便于工作交接和分享 ``` ### 工作部分 #### 运维需要一些理论 技术无死角 > 当前涉及技术完全可控，不忽略任何细小变化 知识无死角 > 掌握横向知识（业务逻辑、工作流程） 经验无死角 > 问题的处理要进行记录、整合、分享 沟通无死角 > 领导是对外层级，对内部工作要做到信息共享 #### 怎么对待工作 ``` 追着事情走，别等事情 领导不问，不要说过程 没有结果前，不要告诉领导任何消息 遇到问题，先微笑 解决单点问题 工作有不确定的， 整体推测一遍后，尽量减少问问题的次数 ``` #### 合并业务时，第三方业务不要和自主业务混合 ``` # 背景 有些老旧业务要整合，希望把所有都整合但被拒绝 # 原因 有漏洞的业务（dicuze） 不要和其他业务混合在一起用 因为如果一点被攻破，所有业务都会影响 ``` #### 当你在工作中没了目标，看看这篇文章 ``` 关于技术提升 （内容摘自《架构师之路》沈剑老师的一篇文章） 面过不少同学，我必问的一个问题是，“为什么想换工作”，不少同学的回答是： “觉得自己到瓶颈了，原来的公司学不到东西了。” 然而面试聊下来： （1）基本功不牢固（语言，数据结构，算法等）； （2）工具不熟练（数据库，缓存，队列等）； （3）业务架构，系统架构不精通； 此时我就非常诧异了，明明有很大空间，为什么会有“学不到东西”的感觉呢？ 很多时候，是行业浮躁，是我们自身浮躁，以为自己很厉害，实际上却是半吊子。 我们 不妨问问自己：基本功打牢了么？工具熟练了么？业务搞透了么？架构合理么？是公司技术最牛逼的人了么？ 画外音：都不是公司技术最牛逼的人，怎么能说没有提升了呢？ 别说工作中用的东西千篇一律， 别说一直在做业务， 别说没有技术含量， 不妨再问问自己： 监控到位么？自动化程度如何？做类似的业务，扩展性如何？高可用保证了么？知道系统瓶颈在哪里么？ 问过自己之后，或许你会发现，并不是自己没有提高，而是过于浮躁。不是没有东西学，而是内心的惰性，不愿意去发觉自己不懂的东西。 真的，脚踏实地的，持续学习和提高吧！ ``` #### 关于招聘 ``` 更好的候选人永远会有，要耐心等待 不要被表面迷惑，有的看着踏实，实际只是表面功夫 为什么有些公司不爱招女生，担心怀孕仅此而已 ``` #### 工作中，不要被事情影响情绪 ``` # 这是目标，我并没有达到 工作中没有任何事情可以让我心情起伏 ``` #### 不要想着在工作时间学习 ``` 如果你在工作时间学习，只有两种可能 1. 你进入了刺猬状态（我起的名字） - 什么是刺猬状态？工作中遇到压力、挫折后想逃避，想跳槽，想学点东西就走人。这时任何打扰你学习的人，都会反感，变成一只刺猬，工作态度变差。这里只有一句话，要有职业素养。 2. 工作基本掌控，别人不会主动找你，可以安心睡觉 ``` #### 新入职工作从哪入手工作 ``` # 应以日常工作为入口 常规任务处理（工单，数据变更） 备份，备份可用性检查，备份字符集检查 暂时不要去过多的梳理业务关系 ``` #### 运维中的二八定律 ``` 运维中设计的软件，20%的参数管理着80%的性能 运维中需要处理的技术工作有两种：故障和性能问题 运维中，领导更关心原理，因为原理=处理方法，初期不要过度关注性能 ``` #### 基于二八定律，学习一个开源软件方法 ``` 1. 理论学习 - 了解功能和配套软件 - 了解大概原理 2. 部署 - 按照最简单方式部署，能YUM不编译 - 了解基本使用方法，并测试 3. 研究20%性能参数 - 只关注最重要的20%参数 - 掌握他们的原理 4. 了解软件的限制和主要的坑 5. 准备测试环境，开始使用 ``` 例：基于ELK的数据收集分析展示系统 ``` 最开始接触ELK的时候还没有Beats组件，使用Logstash收集数据，太重。实际学习中，应该关注变化的东西，Beats组件很轻量级，要尝试。 先不考虑集群，rpm包安装单实例，不考虑日志过滤，先传到ES，Kibana展示，看到效果。 下面有两种选择：一是研究ES集群和Logstash日志过滤，二是学习Kibana如何出数据，展示数据。 ``` #### 工作中主动推行一个开源软件 ``` # 请先考虑能否降本增效 1. 了解原理和结构（非常重要） 2. 了解应用场景 3. 搭建并熟悉主要功能（基于当前业务） 4. 进行压力测试，基于原理，模拟日常运维场景（考虑极限情况） 5. 私下找有兴趣的开发参与，并提出需求 6. 编写技术方案 - 主要体现原理（非常重要） - 根据当前业务量，预估压力（并发、数据量） - 体现带来的变化和运维成本（提升了什么、降低了什么） 7. 准备PPT为领导汇报，附带技术方案 ``` 举例：Piwik用户数据收集分析系统（开源分析平台） ``` 1. 简单部署 2. 关注核心功能（嵌入js、数据收集展示） 3. 理解原理（数据收集、写入、展示） 4. 压测 5. 编写技术方案 6. 汇报 ``` #### 组员工作出现失误， 你该怎么做？ ``` # 起因 >梳理服务器，转换到虚拟化，一台服务器关停2个月后清理，但清理服务器后发现有一个半年才用一次的边缘业务在使用，该服务器中的数据库无备份，但此事无人知晓。 # 过程 > 经过思想斗争后，组员向领导（技术总监）汇报了此事。 # 这样做 1. 一起想解决办法，但数据库的确不能找回； 2. 一起想重建方法，需要尝试去找之前的人； 3. 宽慰组员，要去做一些事的时候一定会触碰到一些东西，造成一些影响，别往心里去，下次注意； 4. 最终通过代码重建了数据库 ``` #### 工作先规划还是先做？ ``` 如果你可以掌控自己的想法，不会跳脱目标之外，建议先规划。 否则建议你做以下几件事 1. 确认这项工作是有意义的 2. 确认结果是总体目标中需要的 3. 去做一部分，重复步骤1和步骤2 ``` #### 我怎么带人和面试 ``` # 不要给没有干过运维的人研究一个新东西的机会 没有真正干活底层运维的人（没手动更新、监控、打包部署、人工管理10台以上机器），千万不要让给他研究一个新东西的机会。 ``` 案例 ``` 客服转运维，3选1，给了视频让他们学习，最终选择了一个人搞zabbix 部署-->安装-->配置-->研究功能使用，到了这一步，干不下去了，不想搞了。原因呢？ 1. 他不问我不主动教他。 2. 给他的解决办法他觉得我在敷衍 3. 觉得学这个没用。 没有吃过苦的人，是不会知道能踏实研究一个东西是多么幸福的事情的。 ``` #### 如果领导给你安排任务和工作，请给回应 ``` 难倒你觉得领导是没事给你安排任务么？ ``` #### 我面试关注的地方 ``` 1. 工作方法，工作态度 2. 学习方法 3. 技能（优先级最低） ``` 面试态度 ``` 宁可招1名运维工程师干一年，但能给运维工作带来改变的人，也不要来2年，不求上进的人。最终这些人就是负能量的源泉。 ``` 工作中，那些人值得培养 ``` - 有能力（掌握需要的技能），技术放权，激发主动性，深入研究。 - 有执行力（具备学习能力，还没学会），明确学习路径，知无不言。 - 有态度（愿意学，不会方法），打牢基础，完成基本工作，锻炼耐心。 ``` > ##### 明确一点：有些人是不合适运维的。 #### 请尊重生产环境，哪怕是一台测试机 ``` 因为上面可能跑着不常用，但重要的业务。 ``` #### 不要为了解决一个问题，引入另外一个问题 ``` 来自：赵舜东，赵班长 ``` #### 我们一直都信奉再好的技术和框架如果不能给企业带来业务价值，就没有太大意义。 ``` 摘自《企业IT架构转型之道》 ``` #### 故障处理方法 单一软件故障（不紧急） ``` 1. 定位报错，无明显报错，去日志定位 2. 翻译报错（本人英文全靠google翻译） 3. 百度报错（90%都能找到），找不到就google 4. 从3-5中答案中分析最优可能的解决办法 - 如何分析？博客准确率最高，基本都是处理过的总结。 - 同样问题，不同办法怎么办？ 看那个有理论依据 - 有些解决方案如果都是相同内容，大家转载，优先考虑 - 官方文档查找具体参数 5. 整理文档，想上级报送故障及解决办法 6. 修改前记得备份相关配置，切记直接修改 ``` 单一软件故障（紧急） ``` 1. 定位报错，无明显报错，去日志定位 2. 翻译报错（本人英文全靠google翻译） 3. 百度报错（90%都能找到），找不到就google 4. 测试环境修改，并重启，观察日志，减少影响 5. 报领导批示 ``` 网络故障 >前提：在运维的每一层都设置监测点，分层定位网络故障 ```shell 接入设备-->安全设备-->4层反向代理服务器-->7层反向代理服务器-->业务服务器 ``` 业务故障 >前提：能够“单独”监控到所有集群的Web服务器（通过定义特殊域名） ``` 区分整体故障还是部分节点故障-->定位Web服务器-->快速扩容-->下线故障设备-->定位原因 ``` ### 个人提升 #### 如何排错？(2/3/4无先后顺序) ``` 1. 看并且看对日志 2. 百度/Google 检索报错 3. 通过官方文档核实 4. 排除了基本故障（防火墙、Selinux、权限） ### 搜索引擎怎么用？ #### 搜索 "服务名称 + 故障描述 + 报错的ID + 报错的主要部分" **注意：用空格隔开；私有内容，不用复制** ``` 例： ```shell Last_SQL_Errno: 1146 Last_SQL_Error: Error 'Table 'mysql.t1' doesn't exist' on query. Default database: 'mydb'. Query: 'insert into mysql.t1 select 1' ``` 搜索内容，注意增加空格，不要写一句话 ```shell MySQL 复制 1146 Error doesn't exist ``` #### 怎么向别人提问？ ``` 1. 前因（环境） 2. 后果（报错） 3. 尝试了哪些处理（如果你没baidu过，就别问了） 4. 将上面内容整理到文档中，方便别人查看 5. 别说废话，别穷嘚瑟（三大忌） - 请xx大神给看看（不好意思，我没那么自信，你自己等大神吧） - 别@管理员（有事说事，@毛线啊，我没事让你@玩的啊） - 别说废话“请问有人会MySQL么？”（不好意思，没那么大口气说自己会，等着会的人吧） 6. 麻烦您问完问题在这候着，别人回复你给个回应，别放个屁就走了 7. 麻烦有结果及时反馈，公布到群里，然后单独谢谢帮助过你的人 ``` 例：遇到问题怎么问？ ```shell 请教个问题 1.环境描述： - KVM虚拟化 - 操作系统：Centos7 x64 - 桥接网络 - IP地址192.168.0.100 - 网关192.168.0.1 2.故障描述： - 真机无法连接虚拟机，虚拟机ping不同网关 3.尝试了哪些： - 防火墙关闭 - 服务器重启 - 修改过IP地址 4.个人怀疑 Centos7 网卡名称是随机的，但是我的KVM安装后，自动是Eth0，不知道和这个有没有关系，谢谢。 ``` #### 咨询解决方案怎么问？ ```shell 1.需求描述 - 核心需求 - 其他需求 2.需求拆解 - 根据核心需求逐渐细化 - 考虑压力、并发、业务类型 - 考虑硬件（CPU、内存、磁盘IO、网络IO） - 考虑软件（系统、软件选型） - 考虑日常维护成本 - 考虑投入成本 - 各种限制描述（只能选型某种硬件、某种数据库、某个品牌、不允许使用开源软件） 3.针对不同需求提出自己的方案 - 独立思考 - 描述需求，提出解决方案 4.总结自己的解决方案和投入 - 合并需求和解决方案 - 统计经费、各种成本 ``` 想起一句话，能把问题描述清楚，70%问题都已经能解答了 #### 学习技术时如何确定优先级？ ``` 1. 自我驱使学习，只是为了学习技术，优先前者（稳定性和坑）。 2. 领导交办的研究课题，优先后者（功能和应用场景） ``` . 1