mod

极客时间专栏/赵成的运维体系管理课/个人成长/38 | 我是如何走上运维岗位的？.md

@@ -0,0 +1,102 @@
+<audio id="audio" title="38 | 我是如何走上运维岗位的？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/00/3a/002c36052581f89e060ff405f38d673a.mp3"></audio>
+
+在专栏介绍中，我简单分享了自己为什么会走上运维这个岗位，一是责任心使然，出现问题时总是会主动冲在前面解决，另一个是在这个过程中技能提升得很快，很有成就感。不过当时受篇幅所限，并没有完整说明，所以今天我想再来聊一聊这个话题。
+
+聊这个话题还有一个出发点，就是当下业界对运维的认知和定位还是存在很多问题的，有不少贬低运维的言论，所以我想结合自己的经历谈谈对这个事情的看法，期望能够带给你一些启发。
+
+## 我是怎么开始做运维工作的？
+
+我做运维是在加入华为1年后开始的。在华为内部，我从来没有听说过任何贬低运维的说法，反倒是从华为出来，才开始听到一些言论，比如运维背锅、运维层次低等等，当时感觉还有点怪怪的，这一点下面会再详细讲到。
+
+我当时是在华为电信软件部门，大家熟知的短信、彩信、智能网、BOSS计费系统以及运营商客服系统等都是这个部门的产品。我到公司没多久就进入了一个新成立的项目组，为运营商开发一个阅读类互联网产品，因为是工作后参与的第一个正式项目，从需求讨论、方案选型、代码开发到上线这样一路跟来下，几乎倾注了我所有的热情。当时完全是封闭式开发，除了吃饭睡觉，其它时间基本都用在这个项目上，周六日都是泡在公司的。
+
+项目上线之后，基于运营商海量用户的积累，业务量很快就增长上来了，按照惯例，各种系统问题、故障宕机也随之而来了。当时我们团队规模不大，大家也都是齐心协力，出现问题我们总是一群人一起冲上去解决问题。之所以有这样的反应，主要是因为不忍心看到自己和团队一手打造出来的系统出问题。在华为，软件质量的荣誉感胜过一切。
+
+因为我经验尚浅，所以一开始都是跟在后面看着主管和老员工解决，后来对于一些疑难问题，我就会主动要求接过来研究一下，有时候一个问题要研究好几天才会有些眉目，不过也是在这样的一个过程中，随着解决的问题越来越多，经验也就越来越丰富，很快就成长了起来。
+
+再加上我一直是出现问题后，第一个做出响应和冲到最前面的那个人，主管和团队也对我有了足够的信任和认可，也正是因为获得了这样的信任和认可，后来我得到的成长机会就越来越多。
+
+这里就分享一点：
+
+- **要敢于承担责任，敢于表达自己的想法**。特别是对于职场新人，只有承担，且敢于承担更多更重要的责任，才能够快速成长起来。一些重要事项，主管肯定是优先安排最稳妥和靠谱的人去做，这个时候老员工的优势会更明显，作为新人或经验尚浅的员工，如果没有积极主动的态度和令人放心的表现，很多好机会往往就与你失之交臂了。
+
+当时，我们解决完问题，不仅仅是内部解决完就好了，还要给客户汇报。说简单点，就是把问题原因、处理过程和后续改进措施，用客户能够听懂的表达方式讲出来。一般都是先用邮件发送正式的报告，然后再当面做解释和汇报。当客户不理解、不认可的时候，你就要花更多的时间和精力想办法去表达清楚。
+
+说实话，我当时认为这是非常浪费时间的事情，我想要是把这些时间都花在技术研发上该多好。不过，多年以后回过头来看，这个过程对于培养、提升自己的“软技能”是很有帮助的，主要锻炼了以下几个能力。
+
+- **能站在对方的角度考虑问题，或者说要有服务心态**。很简单的一点，你不能拿着一堆晦涩难懂的技术术语去给客户解释，而是得用客户听得懂的业务语言解释。
+- **文字表达和口头表达能力**。不论是书面的还是口头的，表达一件事情都要有清晰的逻辑，把前因后果理顺畅，先有结论，然后分条陈述。我现在能写这么长篇幅的专栏文章，很大程度上也是受益于这个过程中写报告的锻炼。
+- **从更全面的角度看待问题**。有时候有些问题可能不仅仅是技术层面的问题，也可能出在其他方面比如业务逻辑、第三方、用户自身以及信息沟通上。一开始，面对这种问题我都是直接反馈说不是技术问题，跟我们没关系，可以想到这样的回答总是会被客户诟病。慢慢地我才发现，即使问题最终不是由你来解决，也应该全面考虑问题，跟客户一起讨论最终的解决方案，这样才会得到认可。后来我发现这是一个技术人员普遍存在的问题，比如，“我的代码没问题”，“在我的电脑上是好的”等等，其实就是缺乏全面看问题的意识，也是缺少站在对方角度考虑问题的意识。
+- **首问负责，问题闭环**。问题找到你，你就要端到端负责解决，最终要给客户一个满意的答复，即使问题解决不了，也要能够获得客户认可的反馈。而且，如果这个事情是比较复杂的，需要时间和一个过程来解决，一定要在过程中及时反馈，而不是迟迟不响应。一个最常见的反模式就是“这个跟我没关系，你去找谁谁谁吧”，一句话就把客户的满意度给消磨没了。
+
+这么多年工作经历下来，我感觉**对我个人职业发展帮助最大的，恰恰是上面这些良好的工作习惯，没有这些好习惯的扶持，单纯的技术技能成长很容易遇到瓶颈。而且，如果说技术技能是在不断更迭变化的，上面这些做事的基本原则却可以随时随地迁移使用。趁早养成良好的职业习惯，会对个人发展有巨大的好处**。
+
+对这个阶段做个总结，我更愿意承担一些非常具有挑战性的工作，成长得就比较快。同时，在客户层面，我又相对比较愿意表达见解和意见。虽然那个时候没有什么沟通技巧，也没什么表达技巧，甚至有些时候是笨嘴拙舌的，但是，很多时候技巧是次要的，最关键的是要敢于表达，当团队需要这样一个角色时，是不是有人能够站出来承担起这个职责。慢慢地我在客户层面也得到了一定的认可和信任，成为一个真心诚意、关键时刻能靠得住的一个人。通过这样一个阶段，我不但在技能深度上有了积累，在广度上也体现出了明显的优势。
+
+## 我为什么会把运维当作职业发展的方向？
+
+这个阶段大约也就1年左右，我的主管就开始跟我沟通，由我来组建这个产品的运维团队，把线上运维、稳定性和部分客户沟通工作完全交给我。
+
+可能有些人觉得做运维是很低级的事情，让你做运维就是让你去填坑，其实对于这样的言论以及今天开头提到的什么运维背锅论，我是十分反对的。当然，更多的时候我也不是去解释，而是靠做事情来证明。
+
+说回到当时的事情上，当时主管在跟我沟通独立带一个运维团队时，我的感受不仅仅是晋升层面的喜悦，更多的是因为能够做运维而感到非常自豪。
+
+为什么会非常自豪，这就不得不提到华为内部，在当时来讲，就已经有非常完善和先进的运维体系和运作机制了，我们一起来看一下。
+
+在华为内部，运维是非常受尊重而且非常关键的岗位。如果你在研发团队中一直写代码，没有做过运维工作，是很难晋升高级别岗位的。所以华为的架构师、技术经理甚至是更高级别的研发主管，按照不成文的规定，都默认要在运维团队轮岗过，然后再选拔出来。而且这里面最最关键的是，运维这个岗位不是你想做就能做的，是有条件要求的。
+
+下面我们就来看看有什么样的条件要求。我当时是在华为电信业务软件部，华为的运维体系分为一、二、三线，我们分别来看。
+
+**1. 一线维护**
+
+这个团队是负责产品的交付服务和后续的客户服务工作。从技能上，很像传统运维，主要是对网络设备、硬件主机和操作系统层面要熟练。一方面要负责交付的项目管理；另一方面，也是非常重要的一点，要对一线客户满意度负责，也就是客户反馈的所有问题，甚至是客户工作中表现出来的喜怒哀乐都要关注。
+
+一线维护，最重要的就是必须要有非常强的服务意识。
+
+**2. 二线技术支持**
+
+因为一线维护面对的是单个具体的运营商，在遇到一些问题的时候，往往没有经验，但是二线因为要面对某个产品全球的局点问题，所以在经验上更容易沉淀和积累。当某个一线团队遇到没有经验的问题时，二线有可能就可以很快很好地帮忙解决，而不用直接透传到三线。
+
+同时，二线还要做好统筹协调，因为一线过来的问题不仅仅是产品本身问题，也可能是网络设备、硬件、操作系统、存储甚至数据库等的问题，这就需要二线帮助一线协调专家资源进行处理，而不是一线再一个个找人，这时一线只管反馈问题即可。
+
+二线技术支持，大多由产品研发或者一线维护经验的人员抽调上来的，即使没有这些经验，也要下放到一线去锻炼很长时间，两三年都有可能，所以技术和经验上都相对更加全面，同时能够有较强的推进协调能力。
+
+**3. 三线研发维优**
+
+到了三线就是研发团队中的运维团队了，这个团队在华为叫做维优团队。这个团队就很牛了，一般都是从开发骨干精挑细选出来的，一方面是为了锻炼人，另一方面也是为了在出现问题时，能够有最专业、能力最强的人响应处理，因为电信级业务是国计民生的基础设施，一般传递到三线的问题，都是比较严重或者疑难的了，必须投入精兵强将第一时间解决问题。
+
+处理问题的过程中，还会不断完善工具体系，提升日常维护和问题定位的效率。因为三线同样要面对全球局点问题，所以7*24响应，而且常年无休，比我们现在互联网运维的工作负荷要大得多，所以这个团队成员一般做个1~2年就会转岗晋升，不然身体肯定是承受不住的。
+
+三线研发维优，这个团队的成员就像军队中的突击队或尖刀连一样，总是冲在最前面，在高压状态下，解决最复杂、最棘手的问题，所以从选拔阶段，就有非常高的要求。最终经过这个团队磨练出来的人，技术能力、沟通协作能力以及全面解决问题的能力，都是非常突出的。自然地，在晋升发展方面就会有更大竞争优势。
+
+上述这样一个非常严密的一、二、三线运维机制和协作体系，各条线各司其职，发挥各自优势作用，串联起了客户、产品和研发整个技术支持体系，基本上就支撑起了华为电信软件在全球局点的技术支持和服务工作，这一点还是很强大的。
+
+也因为各自都有独特的价值体现，所以运维岗位上人员的存在感和成就感就会比较强，当然就不会觉得做运维是很低级的事情。同时，因为人员非常优秀，能力突出，这个岗位得到尊重也是必然的，甚至是令人向往的。
+
+其实，能够得到尊重，还有非常重要的一点，就是来自华为对客户和用户的尊重，真正的把“客户第一”融入到了整个公司的组织架构和运作机制中。
+
+这里我们不做过多发散，理解下来就是**谁离客户最近，谁对客户负责，谁就能代表客户，谁就有最大的话语权，甚至是指挥权和决策权**。体现在上述我们所说的运维机制上，就是：一线的声音，代表了客户声音；一线反馈到二线的问题，二线必须响应；二线传递到三线的问题，三线必须响应。
+
+当然，问题级别不同，响应效率可以不同。同时，三线可以根据客户现场情况，以及问题严重程度，对问题进行升级，以知会到更高层级的主管进行关注。
+
+在考核上，如果一线提交的问题，最终被定性为二线支持问题，或者三线研发质量问题，那二、三线的全年考核将会受到影响，如果是频繁出现问题，那就会受到严重影响，而且各级主管要承担连带责任。
+
+这套机制的根本目的，还是为了促进整个体系能够以尽快解决问题、提升软件质量为目标。整个团队树立起这样的观念，就自然会对质量和问题有敬畏感，研发维优那个时候大多都是远程电话与一、二线沟通，潜意识里就会把一、二线作为他们的客户，同样保持谦卑和尊重。
+
+所以，无论是从对运维的定位上，还是整个公司文化以及运作机制上，都形成了对这个岗位的高度定位和尊重。
+
+说回到我个人，因为当时项目性质的原因（前面提到本质上是一个互联网形态的项目），是高度定制化的，并不是传统电信业务的产品形态，所以当时我们无法直接获得一、二线的支持，所有的运维工作都由研发团队完全独立承担，当时我就是把一、三线的事情都做了，前面很长一段时间是既做开发又做三线维优工作，对我技能上的提升帮助非常大。再往后因为精力有限，在后端维优团队建立起来之后，我就花更多时间做一线工作，贴近客户多一些，这里就对我之前说的职场软技能的提升有很大帮助。
+
+当时华为的三线研发维优，其实很像Google的SRE岗位，各方面能力要求很高，不仅仅是软件开发这么简单，所以当时让我去做运维，并且给到我足够的授权去组建和带团队，就相当于让我去做SRE这样高端的岗位，我自然会觉得非常自豪。
+
+再往后，在这个专业方向上做精做细，形成差异化的优势，自然就会有更大的收获。
+
+## 给我们的一点启发
+
+这样的一个发展过程并不是我刻意设计过的，机会也不是刻意争取到的，就是**平时多做一点，做得认真一点，确保最终能够拿到结果，而且稍微努力一下，尽量拿到比预期好一些的结果**。在这个过程中，随着个人能力的提升和全面发展，后续各种机会也就随之而来了。
+
+如果让我总结就是这么平淡无奇，如果让我给出个人发展建议，想要从普通做到优秀的话，就是上面几句话。
+
+岗位上，可能不会跟我一样去做运维，但却一样可以做到优秀的架构师、技术专家、项目经理或产品经理等等，只要你有心即可。
+
+最后，你在个人成长和实际工作中遇到过哪些问题呢，有哪些感悟和心得，欢迎留言和我讨论。如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！

极客时间专栏/赵成的运维体系管理课/个人成长/39 | 云计算和AI时代，运维应该如何做好转型？.md

@@ -0,0 +1,112 @@
+<audio id="audio" title="39 | 云计算和AI时代，运维应该如何做好转型？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6c/85/6c7578d1ed2ef783ed4f3f3cb6d98785.mp3"></audio>
+
+今天我们来聊一聊，在云计算和AI时代，运维应该如何做好转型？今天的内容可以说是我们前面运维组织架构和协作模式转型的姊妹篇。针对运维转型这个话题，谈谈我的思考和建议。
+
+我们先来看业界的三个典型案例，一个来自国外，一个来自国内，最后一个是我自己团队的案例，都非常具有代表性。
+
+**先看国外Netflix的模式**。
+
+Netflix从一开始就强调开发人员进行自助化运维。我们第一篇文章中就介绍到，Netflix内部的运维工作全部都由开发人员完成，平台也由开发自己完成，只保留极少的Core SRE角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是其电商业务，还是AWS公有云服务，全部都由开发搞定。
+
+这样的团队因为其技术前瞻性，微服务以及分布式这样的技术架构早已落地，再加上其超强的技术能力，所以可以从一开始就这样来做。
+
+**再看国内阿里的模式**。
+
+阿里技术团队在2016年左右，也开始进行“去PE”的组织架构调整，原来需要PE完成的运维工作，全部由开发承担。原来的PE要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应调整的PE就只能离开了。之前在业务稳定性保障过程中起到核心作用的PE，随着各类工具平台的逐步完善，在高度自动化之后，最终也只能面临职业和技能上的转型。
+
+这种模式，与Netflix正好相反，也就是一开始技术能力无法满足要求的时候，能靠人就先靠人，然后过程中不断完善各类自动化平台。
+
+**最后，再说说我自己的团队，发展过程中的模式。**
+
+我大致回顾了一下，发现从去年年初到目前，将近两年的时间里，我自己的团队也没有招聘新的应用运维人员了。并不是没有合适的人，我总结了一下主要有两个原因。
+
+**第一个原因**，随着自动化逐步完善，效率不断提升，单个PE能够支持的业务变得越来越多；同时，很多事情开发都可以自助完成。
+
+**第二个原因**，我有意识地招聘具备开发能力的人员，他们入职后一方面参与各类平台的开发，另一方面还要定期轮岗做一些运维工作。后来我发现，只要有效进行引导，同时具备运维和开发能力是不成问题的。
+
+所以，结果就是，应用运维的岗位需求已经没有这么强烈了。从趋势上看，跟阿里的发展过程非常相似。不过这个过程，我从来没有刻意地设计过，基本算是顺其自然。
+
+从上面的这几个案例来看，无论哪种情况，就运维来说，随着日常重复的人工操作被逐步自动化之后，如果还是固守原有的工作模式和思路，能做的事情、能够提供的价值，一定会越来越少。终究有一天，我们会面临和阿里PE同样的转型问题，而且这个转型是在可预见的短期内就会到来。
+
+既然预见到了趋势，那下面我们就来谈谈应该如何面对。
+
+## 应用运维的转型
+
+如果只允许给一条建议的话，我给出的建议就是：**学会写代码**。
+
+我们早期的运维岗位，基本上都不会对代码能力有很强的要求。所以对这个岗位上的同学来说，这一点就成了技能上最大的短板，也成了后续职业发展的瓶颈限制。
+
+但是，运维行业发展到现在，无论是从趋势上看，还是从我们现在所经历的实际现状来看，单纯靠人力维护的投入越来越无效。
+
+所以，**无论是我们做运维转型也好，还是做其它技术转型也好，具备代码开发能力，已经成为一项必备技能**。
+
+这里多说一点，我们大多数做运维的同学不具备代码开发能力，并不是自身的能力问题。很多情况下都是因为不够自信，对写代码心存畏惧，担心自己写不好，所以一开始就把自己给限制住了。如果是这样，我给的建议再多也没用，关键还是要靠自己先迈出第一步。
+
+现在我自己的团队中，有很多同事做了多年运维工作后，因为乐于尝试和挑战，很快就可以独立编程，而且因为自身有很多一线运维经历和经验，可以说即懂业务又懂开发，反而比单纯做平台和工具的运维开发更有竞争力。
+
+下面是一些具体的建议。
+
+- **代码开发上，我的建议是可以从Python、PHP或Go这些上手比较简单的语言开始**。这里不是写脚本，一定要能够实现完整的业务功能或流程。一开始尝试去做一些简单的工具，实现一些简单的功能，再往后可以通过一些复杂的业务场景深入下去。一旦场景的复杂度高了，就会涉及到更高的开发技能，比如并发、缓存、消息甚至是服务化框架等等。关键是敢于迈出第一步，然后逐步转变。相信我，真的没有那么困难，我身边有太多的优秀转型案例，都是这么过来的。
+- **提升产品意识**。这里不是要求运维同事都成为优秀的产品经理，或者具备很强的产品设计能力，而是一定要有产品意识，只要有这么一点点小转变就会带来大不同。我简单说明一下，我们很多运维同事，甚至是资深级别的，往往还是习惯于处在最末端，前面有什么事情找到我，我就处理什么事情，属于被动响应类型的。但是，如果你有产品意识，能够将你所做的事情整理汇总起来，然后做一下流程上的串联，再把流程中每个环节步骤的功能进行详细描述，同时在梳理的过程中，将一些不合理、不规范的地方进行标准化约定，也就是我们前面说的标准化过程，然后输出的内容就是平台开发所需要的需求分析和产品PRD的雏形了。如果能将所做的事情从单纯的运维操作转化到这个维度，那我们呈现的价值就完全不一样了。
+- **提升技术运营意识**。这一点跟上面类似，简单来说，就是如何根据需求，把承载了标准化和规范体系的工具平台真正落地应用起来。同时，在落地的过程中，通过问题收集和一定的数据分析，然后再回到产品设计和需求实现流程中进行改进，形成一个良性的闭环。
+
+在阿里的PE转型过程中，有一部分转型去做效能工具研发，有一部分经验丰富的资深运维就转型去做了技术产品和技术运营这样的运维专家角色。对于开发人员已经可以自助完成的部分一线运维工作，运维专家还会在这个过程中对开发做一些赋能。
+
+所以，对于当前运维岗位上的同事来说，有这样一个先天优势来承担这样的职责，可以参考阿里PE转型的经验，根据自己的优势特点提前做好方向规划。
+
+## 云计算和AI带给我们的挑战
+
+机遇与挑战并存，上面我们更多地讲了机遇，但是与此同时我们也要看到挑战，甚至是危机。
+
+而最大的挑战和危机往往都不是来自内部，当我们还在纠结如何不被开发替代的时候，外面的技术环境已经发生了很大的变化，而这种变化带来的将是颠覆性的改变。
+
+有两个最大的外部因素，一个是**云计算**，一个是火热的 **AI**，我们分别来看。
+
+首先，云计算发展到今天，已经不是我们想象中的只能提供IaaS服务的云平台了，目前各大公有云上的PaaS产品体系也已经非常完善。我们前面讲的各类分布式中间件产品都有覆盖，而且这些产品，还都是各大公有云平台公司在自有业务上锤炼出来的非常优秀的产品。
+
+简单一句话，现在我们去做一个业务，基于这些基础服务，完全无需自研纯技术产品，只要专注业务逻辑开发即可。我了解到国内某新兴的O2O，每日超过千万笔的订单量，除业务代码外，其它基础层面的服务就完全依赖于某大型公有云的IaaS、PaaS以及周边的各类服务体系。
+
+这种情况下，非但不再需要大量的如SA、网络工程师、DBA以及应用运维这些岗位，就连技术门槛较高的分布式中间件研发岗位也会大量缩减，所以这个挑战和危机就会非常大了。
+
+这种情况下，我们应该如何面对？其实，我在前面的文章中已经给出答案，大家可以先回顾一下，然后再往下看。
+
+这里的答案就是，**从价值呈现的角度来思考我们可以做什么**。至于做什么我前面也提到过，比如持续交付以及稳定性保障体系。当然根据业务的不同特点，远不止这些内容。这些都是跟业务自身层面相结合的，与平台无关。与业务结合，就会有个性和独立的地方。**如何根据自己的业务特点，找到跟业务相切合的价值呈现点，是我们每一个人应该去思考和探讨的。只有找到这些点，我们做的事情才会有价值和意义，我们所在的岗位才会有价值和意义**。
+
+然后，再谈谈AI。这里说明一下，我们现在谈到的AI，其实大部分情况是在谈论AI的一种实现方式，就是机器学习算法。关于这一点我在InfoQ分享过一篇文章，我把链接附在文末，如果你感兴趣可以读一读。
+
+AI和Ops的结合，更多还是场景驱动的。就是我们要处理的数据量越来越多，面对的场景越来越复杂，而且会大大超出我们人力的认知范畴。比如BAT这样的公司，几十万台服务器的规模，出现一个问题，我怎么能够快速发现，快速定位，并最终快速恢复？如果是几百甚至几千台服务器，靠人还是可以搞定的，但是几十万台，靠人就不可能了。
+
+所以，这个时候，就需要借助技术的能力，而机器学习算法又正好可以满足我们的诉求。
+
+这里想特别提一点，机器学习算法的应用，是离不开场景和业务特点的，也就是说怎么用还是离不开人，离不开对业务和场景熟悉的人。从我现在了解到的情况来看，很多公司和团队，针对每一个场景都需要投入很大的精力去对某个特定曲线和算法进行调参优化，以确保它们的准确性，也还没有神乎其神地达到完全不靠人的无监督学习。这里面并不是说算法本身不具备这个能力，而是现实场景太复杂，我们不能用简单固化的算法来应对。
+
+说到这里，我想我们应该可以抓住这里面的关键点了，就是**懂线上运维实际情况的人做这个事情，会更加适合**。当然，这是极其理想的状态，因为机器学习算法的应用还是存在比较高的门槛，不仅仅是技术层面，还要一定的数学基础，需要对大数据产品有所了解等等，是个相对复杂的过程。
+
+所以，这里我的建议就是要多去了解，因为未来随着技术、数据和计算能力的提升，AI是一个必然的趋势。**如果一点都不了解，极有可能就会被卡在门槛外面，这就不是转型的问题了**。
+
+## 总结
+
+上面我结合一些运维发展到目前的现状以及呈现出的趋势，做了一些分析和建议。最后我们总结一下。
+
+新时代下，机遇和挑战并存，我们确实面临着岗位和技能的转型。我给出的建议是：**学会写代码，培养产品意识，提升技术运营意识**。
+
+当然，转型这个过程也不会完全是绝对和极端的，以后就一定是一个运维都不要，一个SA也不要，一个网络工程师也不要。但是，我们应该看到，这些岗位会更加收敛。一个是岗位设置上会收敛到各大云平台厂商这里，做专职的基础和后端的服务维护；同时随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。最重要的，这些岗位上的价值空间以及成长空间，将会变得极为有限，不管我们愿不愿意承认，这都是我们不得不接受的现实。
+
+同时，在云计算和AI时代我们面临的这些挑战和危机是可以预见到的，而未来还会存在大量的不确定和我们预见不到的东西，这种情况我下我们又应该如何应对呢？
+
+或许，**唯一的办法就是不断地学习和提升自己的技能，保持对技术发展趋势的敏锐性，及时做出调整和应对，才是根本的解决之道**。
+
+关于今天我们分享的主题和内容你有怎样的感想呢？你是否正在面临转型的困惑？是否已经成功转型，有什么经验？欢迎你留言与我分享讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+**拓展阅读**
+
+<li>
+[AIOps为什么是运维发展的必然趋势？](https://time.geekbang.org/column/article/1365)
+</li>
+<li>
+[AI时代，我们离AIOps还有多远？](http://www.infoq.com/cn/news/2017/08/AI-how-long-AIOps)
+</li>
+
+

极客时间专栏/赵成的运维体系管理课/个人成长/40 | 运维需要懂产品和运营吗？.md

@@ -0,0 +1,65 @@
+<audio id="audio" title="40 | 运维需要懂产品和运营吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d7/30/d7d0bed68388788f5b3edfecd4261730.mp3"></audio>
+
+在《云计算和AI时代，运维应该如何做好转型》这一期内容中，我提到两个转型建议：一个是技术产品，另一个就是技术运营。今天我就更加聚焦地来分享这个观点。
+
+我们运维接触更多的是软件生命周期中的运行维护阶段，我之前总结过一张图，就是在这个阶段要做的一些事情，把它们串起来就是下图：
+
+<img src="https://static001.geekbang.org/resource/image/c1/59/c1677c6e269fa32f94512d6e1767c059.jpeg" alt="" />
+
+这张图的思路应该非常清晰了，而且对照一下我们日常在做的工作，基本上也离不开图中所描述的这些事情。
+
+这里我想表达的是，我们应该从这张图中敏锐地观察到，**研发团队对运维团队的诉求，以及运维呈现的价值已经发生了变化，我们更加需要能够帮助团队建设出高效运维体系的角色，而不是能够被动响应更多问题的角色**。
+
+## 运维的角色转变和价值体现
+
+打造一个运维体系，我们完全可以把它类比为一个产品业务体系。我们公司的组织架构中，针对一个产品或业务，如果要对其进行技术上的实现，自然就离不开类似运营提需求，产品分析设计、业务架构师设计建模、开发实现以及测试保障这样一环套一环的配合，每个角色都发挥着独特的价值。
+
+那么，对于一个运维体系，就相当于是面向研发团队内部的一套技术业务体系，只不过我们的需求方和客户是开发人员，而不是业务人员。
+
+我们对照一下可以发现，运维团队中技术环节的角色是不缺的，但是缺少的是业务环节的产品和运营角色。**但是我们做事情，不一定非要有岗位上的明确设置才能往下做，只要有能起到这个作用的人承担这样的职责就够了**。而这里，**最合适做这个事情的，一定是运维，因为运维是日常线上运维的执行者，只有运维最清楚这里面的细节、问题和痛点，换其他人可能很难能够讲清楚**。
+
+当然了，我们也不能强制要求运维一定要完全具备产品经理和运营经理的专业素养，这样就本末倒置了。这里我们强调的是**运维要有产品和运营意识**，总结起来最本质的就两点：**第一，能将需求讲清楚；第二，能将产品推广落地**。
+
+## 技术产品
+
+关于技术产品，其实主要就是回答以下几个问题：
+
+- 是不是能够把原本靠人工完成的很多工作转化成需求？
+- 是不是能够把日常工作中运维和开发的痛点转化成需求？
+- 是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求？
+
+这个过程中，可以尝试把自己做的事情串一下，用流程图也好，时序图也好，把整个过程梳理一下。过程中每个环节具体要做的事情可以通过文字描述的方式写出来，尽量分条罗列，清晰有条理。这里也可以参考我们前面讲过的内容，把一些标准化和生命周期管理的方法论融进来。这样可以一举两得，我们的标准化制定能力，场景需求分析能力慢慢都提升上来了。
+
+你可以按照我们刚才讲的内容动手做一下，这样整理出来的一份文档或者内容，其实就是一个产品PRD的雏形。如果你想要更进一步，有更加专业的输出，也可以参考了解一些产品设计方面的知识。
+
+当需求提炼出来之后，跟对应的运维开发一起合作，将需求真正落地实现。这样一个过程下来，运维的价值和能力体现是不是就跟之前有了很大的不同呢？
+
+## 技术运营
+
+通过上面技术产品的工作，可以做出一些有针对性的工具和平台来。但是，仅仅有工具和平台还远远不够，因为只有把这个平台真正落地，并产生了实际效果，才是有意义、有价值的。这个“真正落地”就是技术运营要做的事情。
+
+所以，接下来要做的就是落地。
+
+- **平台推广落地**。工具做出来了只是第一步，得要有人用，这就需要去推动落地，让大家都来使用，从而真正给团队带来规模上的效率提升。同时，我们的技术产品也是各种标准和规范的载体，在这个落地过程中，也是标准落地和执行的过程，就需要运维和开发配合做出一些改造，为后续更大规模的效率提升和平台建设打下基础。
+- **线上运行数据分析**。通过我们的平台和工具，对线上业务和应用运行时的指标进行数据分析。比如，应用上线或者每次变更上线后，线上运行的情况是怎样的，容量有没有降，RT有没有上涨，监控有没有异常，用户体验有没有下降，用户和客服的反馈如何等等。以上这些维度和指标就需要通过数据、图表和曲线的方式呈现出来，并基于这些呈现进行分析和判断，做出后续运维决策，比如是否需要扩缩容，是否需要处理问题，是否有改进的地方。**在这一点上，应该要形成对整个业务和技术架构体系改进和完善的正反馈才行**。想想看，业务运营是不是也非常关注业务的数据报表，也要依赖数据情况决定后续的业务运营手段。
+- **过程改进**。平台更多的是一个执行工具，但是工具的使用是要配合大量的标准和流程一起来运作的。比如上面我们提到的，如果一次发布之后流量下降，RT升高很多，面对这样的问题我们应该有怎样的应对机制，这里就体现出管理和流程的重要性了，要解决好不同角色和团队之间的协作问题。同时，过程中需要改进和完善的内容，能够落实到平台和工具的，也要形成正反馈，来提升我们工具和平台的效率。
+
+这个过程可以用下图来表示：
+
+<img src="https://static001.geekbang.org/resource/image/c5/b9/c506e74c3728f120c09243d976ac2ab9.jpeg" alt="" />
+
+**我们面临的业务场景在不断发展和变化，这就决定了技术运营过程也必然是一个持续发展和完善的过程。所以从这个角度讲，技术运营的生命力和竞争力将会是持久的**。
+
+在腾讯，运维就被定义为技术运营，第一次听到这个岗位名称时，感觉还是很贴切的。另外，我在很多大会上听海外的华人工程师分享，Operation这个词都是被直译成运营，但是在国内我们大多还是把Operation翻译成运维，从字面上就把这个岗位的定位给拉低了。
+
+不过，叫什么不重要，只要我们通过今天的内容看到，具备技术产品和技术运营的能力才是最关键的，这一点最重要。
+
+## 总结
+
+最后，我们再总结一下，**运维虽然不是业务系统的实现者和代码的开发者，但是我们参与到了产品技术标准的制定、业务系统运维体系的建设以及后期的技术运营中，这个时候运维已然成了整个技术架构的设计者之一，而且是架构稳定和演进的看护者，这时我们所发挥的作用和呈现的价值已大不相同**。
+
+从技术产品和技术运营的角度再来思考一下运维，现在的运维还是之前那个运维吗？欢迎你留言与我一起讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/个人成长/41 | 冷静下来想想，员工离职这事真能“防得住”吗？.md

@@ -0,0 +1,104 @@
+<audio id="audio" title="41 | 冷静下来想想，员工离职这事真能“防得住”吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1e/a8/1ed2c5218b333207090804e423d1f6a8.mp3"></audio>
+
+本周主要和你分享几个关于个人成长的话题。前面我们讨论了在新时期运维如何做好转型，运维是不是要懂产品和运营这两个内容，都是为了我们能够成长为技术骨干，最大限度地发挥出自己岗位的价值。
+
+今天我们就往后聊一聊，当你从技术岗位转换到管理岗后，应该如何适应新的角色，做好技术管理。技术管理这个话题很大，不是一下子就能说透彻的。所以，我就把处理员工离职问题做为一个切入点，从这个角度说起。
+
+## 从员工离职说起
+
+年末年初，对于任何一家公司或者一个团队来说，最令人头疼的事情就是员工离职问题，特别是骨干员工的离职，对团队带来的影响和损失，以及团队氛围和信心上的影响是非常大的。
+
+其实从员工离职这件事情上，我们还是能够反推出一些在日常管理中的问题，甚至是我们作为技术管理者自身存在的问题。同时，我们还应该从这件事情上找出我们的改进措施，不断提升我们的技术管理和团队建设能力。
+
+**Design For Failure的软件架构设计理念，同样也适用于技术管理工作**。
+
+因为我在EGO会员组（极客邦旗下高级技术管理者社群）专门分享过类似观点，引发了一些讨论。所以今天借着这个问题，详细分享下我在这方面的一些经历和感受，同时我也会给出一些技术管理中的反模式，这些是需要我们引以为戒的。
+
+## 关于员工离职的两个观点
+
+我先给出对于离职的**第一个观点**：**对于离职这个事情，本质上就是员工个人发展和团队发展不匹配之间的矛盾**。
+
+稍微解读一下就是，如果员工个人发展速度很快，而团队提供的空间或机会不足，员工就会调岗甚至离职，寻求更好的利于个人发展的机会；而如果公司和团队发展很快，员工跟不上组织发展的节奏，这种情况极有可能就会被团队淘汰。
+
+反观其它的理由，主管因素、薪酬福利，或者因为世界太大想去看看等等，这些都只能算是表面上的直接因素，或者叫导火索因素。
+
+比如，我们现在经常说的，员工离职最主要的因素之一是与主管不合。如果我们仔细想想，根本上还是因为主管在目标方向上与员工个人诉求达不成一致，或者管理方式上限制了员工个人发展，所以员工选择离开，或者团队主动淘汰，本质上的原因还是离不开发展这个诉求。
+
+但是，有时候员工对于个人成长的不满意和不顺心，无法客观理性地表达，最终就都归因到主管身上；当然作为主管，有时候不考虑员工感受和自身因素，就简单粗暴地进行管理，也不是没有问题。所以看问题要全面，我相信更多的情况是因为双方性格和风格上对不上，并没有什么是非对错，所以一切看开最好。
+
+接着彼此间发展诉求的矛盾这个问题，我再给出**第二个观点**：**对于员工离职，从管理者角度，我们应该理解为必然结果，坦然接受，而不是避而不谈**。
+
+每个人在不同阶段，总会有不同的成长和发展诉求，所以总会有一部分员工在一家公司待到一定年限之后，会为了寻求更加适合自己的机会而离开，因为员工和公司之间的发展不可能始终保持匹配，所以从这个角度来讲，员工个体上的离职是一个正常现象，也是必然结果。
+
+上面这个观点来自于领英CEO里德·霍夫曼写的《联盟》这本书，这里结合我自己的感受和理解谈一下我个人的看法。
+
+如果能意识到是必然结果，那我们要做的就是 **Design For Failure**，**不要试图去完全避免和杜绝离职，而是要有措施能够有效规避离职带来的问题和风险**。也许**最大的问题在于，道理我们都懂，但是能做到的不多**。
+
+所以，下面就来谈谈应该如何做好技术管理。
+
+## 谈谈如何做好技术管理
+
+**1. 帮助员工做好个人中长期发展目标规划**
+
+主管应该跟员工一起确认员工任期内的中长期成长和发展目标，让员工能够在任期内发挥最大的作用和价值，同时能够尽可能地让员工在任期内达成自己期望的成长目标。对管理者来说有一件很重要的事情，就是能够找到团队发展和员工个人发展相契合的价值点。
+
+**这里很重要的一点，做技术管理者，一定要从关注事情、管理事情转换到关注人的层面。要关注人的成长发展，关注成长发展中的问题和疑惑，关怀人的工作体验和心理感受，这个才是管理的核心。一定不要忽略人这个核心要素，人的事情搞不定，其它任何事情都无从谈起**。
+
+我们很多管理者当前是缺失帮助员工做中长期个人成长这件事情的，更多的是做眼前工作的任务指派，甚至是指令性下达。所以现在很多员工离职，都会提看不到发展目标，看不到空间等等。这里的关键还是上面说的管理工作缺失，大多是我们没有帮员工做，而不是真的没有空间了。
+
+这个事情要放到平时做，从团队人数还不多的时候就开始。我的团队30多人，基本每个月都和团队的每一个人做一次一对一沟通。如果实在忙不过来，那就针对核心骨干和有潜力的员工。这个沟通要持续做，并持续调整。如果放到员工要离职了再做，再去承诺，就没有意义了。
+
+**2. 进行梯队建设**
+
+各层管理者和HRBP，要有意识做好梯队建设，确保人才能够源源不断地输入。如有有员工离职能够有人顶上来，至少是有Backup，不至于因为一两个人离职团队就垮掉了。这块就涉及到招聘和“传帮带”机制的建立。
+
+**团队成员不一定都是水平很高、能力很强的人，关键是要合适，能形成合力**。所以团队中既要有经验丰富和技能突出的明星员工，又要有发展诉求强烈的骨干员工，还得要有对各种事情充满激情和新鲜感的小鲜肉。每个梯队的特点和风格不一样，形成互补，发挥各自独特的价值，这样的团队才能够有生命力。
+
+**3. 提升管理意识**
+
+我也是从技术转技术管理，说实话栽了很多跟头，吃了很多亏，才慢慢有所转变，这个过程比较漫长。所以，对于刚做技术管理者的员工，HR团队一定要辅助做好“转身”的培训和赋能，不然就得吃“一将无能，累死千军”的亏。
+
+同时，在这个事情上，更高级主管层面也应该要有些耐心，甚至有些时候要容许一些管理上的失误，不至于一出问题就一竿子打死。因为管理这个事情很多时候是需要管理者个人从一件件事情，甚至是一个个跟头中，一点点去“悟”到的。
+
+## 技术管理中引以为戒的一些反模式
+
+上面讲了做技术管理应该重点做哪些事情，那下面再说说应该少做甚至不做哪些事。
+
+**1. 事必躬亲，不懂授权，不敢授权**
+
+最常见的情况就是所有事情都会参与、过问甚至是干涉，更甚者，因为自己做更快，就懒得指导员工，直接亲自上手做。这样下去，久而久之，就相当于剥夺了员工成长的机会，剥夺了员工独立思考的机会。
+
+我的建议是，对于非紧急的事情，还是让员工自己动手完成。你可以指导，可以给建议，但是不要代替员工执行和思考。
+
+**2. 总认为自己才是最正确的**
+
+懂得授权和分配工作后，往往把自己的想法和经验强加于员工，因为总觉得自己的经验才是最好的，即使思路上和方式方法上仅有一点点不同，也要跟员工争个是非对错。长久下去，员工的主观能动性就没有了，不但容易失去与员工之间的信任，还极容易造成与员工之间的矛盾。
+
+我的建议跟上条相似，可以更多地给员工授权，多从边界条件和目标结果上提问，让员工主动思考。如果员工的方案是可以达成目标的，就可以放手让员工去做，过程中关注进展和风险，多给辅导和建议。
+
+**3. 仅仅关注技术层面，忽略全局**
+
+因为技术管理者大多是从技术岗位上成长起来的，有时看问题难免会片面。典型的一个问题就是只关注技术层面，不看全局。比如外部的需求澄清、进度要求、服务支持等，这些都是非技术层面的，恰恰可能也是一线员工所不擅长的，所以更需要技术管理者来关注。
+
+我的建议，技术管理者一定要先关注全局，然后再看细节。对于管理者的要求，更多的是要“**做成事情**”，而不再是技术骨干阶段的“**做事情**”。
+
+## 总结
+
+最后，我们来总结一下。
+
+对于离职想表达的两个观点：
+
+- 员工离职反应了个人发展与团队发展之间的矛盾；
+- 员工离职是个必然结果，坦然接受，做出应对，而不是谈之色变，或避而不谈。
+
+对于技术管理，这其实是个很大的话题，今天我们提炼一个重点：
+
+- 技术管理者，一定要重点关注人，而不仅仅是事情。这一点是做技术骨干和技术管理者之间的最大差别，也是转变思路的第一步。
+
+在技术管理上，你还有什么疑问，欢迎留言与我沟通讨论。
+
+这里推荐一下我们隔壁的专栏《**朱赟的技术管理课**》，我订购后阅读了很多文章，产生了很强的共鸣，同时也收获到一些硅谷技术公司的先进管理经验，很有帮助。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/个人成长/42 | 树立个人品牌意识：从背景调查谈谈职业口碑的重要性.md

@@ -0,0 +1,97 @@
+<audio id="audio" title="42 | 树立个人品牌意识：从背景调查谈谈职业口碑的重要性" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e7/98/e7a74a17fbeca2ea0d06799155e74b98.mp3"></audio>
+
+求职者的背景调查是我去年频繁遇到的一个职场场景，经过仔细琢磨，我有了一些自己的感受和思考。同时，这也带给我一些启发，让我对自己后续的职场表现有了一些新的认知和调整。
+
+我在这里分享出来，希望能对你有所帮助。
+
+## 对求职者的背景调查
+
+2017年的时候，特别是年初和年中，我陆续接到了几家公司委托的第三方机构，对我所在团队的前成员，甚至是我上家公司团队的员工做非常详细的背景调查。
+
+可能是因为与我相熟，有些公司的主管有时会直接联系我，对某些求职者在我们公司的表现和业绩情况进行了解。
+
+而且这种了解不仅限于我，我团队中的部分员工因为工作年限较长，在同行业的圈子里彼此也非常熟络，所以也会有人直接联系这些员工了解更全面的信息。
+
+**背景调查对于关键岗位和高级别岗位，至少在互联网公司，已经成为了必须环节。而且越关键、越高端，背调审计就越严格。**
+
+不管来自哪一方面的背调，最终被咨询一方的意见，都有可能影响到求职者的面试结果。
+
+第三方背调，一般都是在候选人经过层层选拔之后，在正式Offer发放前做的最后一项审核工作。所以如果在这个环节出现问题，眼睁睁和机会擦肩而过，就十分可惜。
+
+而对于行业同行内的背调，一般会在面试前进行。所以当你参加面试时，面试官极有可能已经对你形成了初步印象和评价，面试过程就可能是这个初步印象的验证过程。
+
+所以，面对这样的情况，我也会非常谨慎。我会尽量客观地给出我的评价标准，比如技术技能、沟通协作能力、态度表现，以及是否有比较突出的业绩贡献等等。
+
+之所以提供这些信息，是为了让对方来判断候选人的自述是否符合真实情况，以便对方做出决策。
+
+但是，两种情况下，我会比较旗帜鲜明地给出我个人的建议。
+
+**第一种，对于我认为特别优秀的，我会给出强烈推荐或者非常推荐的建议。**
+
+**第二种，对于确实存在短板或较大自身问题的，我也会客观反馈，建议对方在候选人面试时或入职后，在管理上多加注意。**
+
+我之所以这样做是因为，别人来咨询我，是对我个人的信任，我既要客观不能夸大，也不能藏着掖着掩盖事实。同时，我也要给出更加真实的一手信息。当然，我在向别人求助时，也期望别人能以同样的方式来反馈我。
+
+## 如何树立个人口碑
+
+谈到这里，你可能会问，既然这个环节我们自己完全不可控，那我们又怎么能确保得到被咨询人正面客观的评价呢？
+
+我的答案是：**背调过程不可控，但是我们自身的表现却从来都是可控的。**
+
+也就是说，我们应该把注意力放到日常工作的表现上来，因为我们所有的评价依据都来自于此。
+
+我们应该常常自问：我在工作中是否能做到积极主动，具备主人翁意识，敢于承担更多更大的责任？我在工作中是否能够不断取得成果，在团队中或跟团队一起作出较大的贡献，取得较大的业绩？
+
+以我之前公司团队的一位同事为例。
+
+这位同事是我们Oracle数据库的DBA（数据库管理员），当时他入职的时候刚毕业一年多，经验一般，但是到了岗位上很快就融入了，经常会给我提出一些在数据库层面的优化改进建议。并且在我们评审通过之后，他会自己主动去落地执行。
+
+在整个过程中，他跟其他团队成员配合得很好。出结果后，还会主动跟我一起去客户那里作汇报。久而久之，我对于他的工作很放心。后来我就放手让他自己去沟通，在他的协助下，我也减轻了一定的工作压力。
+
+后来随着能力的成长，他基本承担起了DB的全部运维职责。他在岗的那两年左右，跟团队密切配合，在确保数据库没有出现过大故障的同时，还输出了很多提升性能和容量的优化案例。（要知道Oracle数据库的优化，能够带来的成本收益还是非常巨大的。如果你了解或维护过Oracle，应该会深有体会。）
+
+在与他共事的时间里，我们更多还是同事关系，但是相比其他人，我会对他抱以更多的信任。后来他转投去别的公司工作。
+
+就在去年，我突然接到一个电话，对方是一家第三方背调公司，代表国内顶级的某支付公司，对他申请DBA技术专家岗位进行背景调查。
+
+这时我脑海里涌现出的，都是他以往种种优秀的表现。所以背调问我的每一个问题，例如表现是否突出，工作态度和责任心如何等等，我除了实事求是地回答之外，还会特别用到“非常突出”“非常优秀”之类的赞扬之词。
+
+这是比较突出的一个案例。其实绝大多数情况下，我们只要能够做到尽职尽责，态度认真，把精力投入到工作上，就不用对背调过于担心。
+
+但是**如果想要树立个人的好口碑，那就需要我们付出更多，要让团队和其他成员明确你独特的个人价值**，就像我上面所讲的这位同事一样。
+
+## 要引以为戒的反例
+
+讲到这里，我也要举两个反例，这都是我在实际工作中遇到过的情况，请你引以为戒。
+
+**第一个，诚信问题，这是高压线，触碰不得。**比如填写个人薪酬信息时，为了想获得更高的薪酬定价，故意捏造事实，肆意夸大之前的薪酬待遇。其实这些都是可以通过背调调查清楚的，如果存在造假，用人单位会直接拒绝。
+
+我遇到的一个真实案例就是，候选人经过了终面，但当我们通知他最后一步背调完成，然后准备发放Offer时，他却反馈不准备接受offer了。
+
+我们当然感觉比较可惜，但通过推荐人了解情况后，才得知他因为虚报薪酬太多，自己感觉心虚而不敢来了。
+
+同样，在工作岗位上千万不要故意制造假数据，或者泄露工作信息谋取个人利益，这类错误触犯的后果将会更加严重。
+
+**第二个，消极怠工问题，这一点我认为是职业道德问题，是令人厌恶的。**比如有的人在离职前的时间里，消极怠工，交接工作时不积极配合，经常迟到或早退，中途睡大觉或者跑出去不知所踪。
+
+可能他认为反正要离职了，一切都无所谓了，也就不再重视个人行为是否妥帖，是否合乎公司规范，是否符合起码的职业道德和职业素养。
+
+而这一行为恰恰会让团队其他人给他贴上“不负责任”“不靠谱”“职业素养欠缺”的负面标签。如此，他在将来背调时，可能就会因为这么简单的几个形容词，而被否定掉了，造成个人职业生涯莫大的遗憾。
+
+当然，如果你因为意见和思路与团队或他人无法达成一致，而闹情绪，传播负能量，为团队协作制造障碍等等，这种消极表现也是不可取的。
+
+## 共勉
+
+在职场中，我们个人的职场信息和表现，就像我们的整个求学经历一样，会被详细地记录、跟踪和完善，这就更要求我们必须要学会树立我们的个人品牌，珍视自己的职场口碑。
+
+而职场口碑的树立，关键还是来自于我们日常工作中一点一滴的表现，甚至是通过某些很细微的工作慢慢积累起来的，这是一个渐进的过程。
+
+俗话说“千里之堤溃于蚁穴”，往往一不留神，因为一件负面的事情或行为，就会使你个人职场口碑和个人品牌瞬间坍塌。
+
+所以，请守住职场底线，让我们共勉。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+