2021 年，我终于愿意面对现实，想说一点不一样的话。
本文内容可能会引起一些人的不适，阅读时大可不必过于计较（其实没啥人看）。
此处本来有音频
可进入 撩保星球 公众号阅读听音频
不务主业
我一直是一个在其位不只谋其政的人，老喜欢给自己加戏。
比如我刚入行（2012年开始从事软件测试工作）的时候，就在思(yì)考(yín)，编程能否节省我的操作成本，在实际工作中，经常会花比别人更多的时间完成任务，因为我花了很多的时间去尝试写一堆脚本。
再比如当我还处于初级测试工程师阶段的时候，经常规(yì)划(yín)该如何改善团队协作与竞争力，还经常总结一堆除了自己不会有人欣赏的分析与报告。
还比如我明明只会软件测试，却总是掺和各种规范和流程，该如何管理代码、如何管理镜像、连如何快速做 POC 我也喜欢插一脚。
这种不务主业的模式，一直持续至今。
如今我既做着软件测试，又搞着 DevOps。
韭菜
以前觉得“专家”“顾问”这些称号一定是严谨且牛哔哔的，一定是具有职业道德和操守的。但实话实说，现在大多数的专家都是没操守的，教别人的那些“知识”，有用没用，自己心里能没点数吗？
这些话也许太得罪“大佬”们了？但告诉别人只要九块九，专家技能就到手，这叫有节操吗？这明明就是割韭菜。我这说得不太好听，但确实是真相。
我这么“仇大佬”，是因为心理不平衡吗？我说不是，你信还是不信？我语气如此淡定，什么仇？什么怨？没有的事儿。
曾几何时，我也差点是其中的一根韭菜，只不过一直心存疑惑，大佬们整天写文章，还怎么搞研究，怎么搞服务，但年少单纯的我始终心存美好，认为大佬们一定是各种霸王，脱发都能防，时间管理也一定是大师，吾等普通人需倍加努力。
如今才发现，且不说工作忙起来有没有时间写文章搞培训，各种经验和案例想分享出来，光脱敏就得花点心思，月更一篇我都得配几个助理。况且，若天天都遇到棘手的案子，这得是多悲惨的职场啊？倘若是在咨询公司，那此等猛虎般操作就更迷离，本就靠卖方案生存的公司会把自己的商业机密公开出来吗？适当透露一些思路倒是有可能，把整个方案都分享出来铁定不现实，分享给你的，保证你看了也白看。
这就好比有一位资深基金经理分享给你投资配置，但你根本没法抄作业，因为一来不知道买卖的时机，二来也不知道这么搭配的用意，最重要的，万一出现状况，你完全不知道应该如何应对。
毒鸡汤
现在市面上的培训真的非常多，有免费的也有付费的，其实培训方的出发点都是基于自己当前的利益点，或是岗位、或是领域、或是某些想法，无可厚非，学习者也各取所需。但培训就培训吧，整天撒毒鸡汤就不太友好了。
一万小时定律是没错，但是随便挑个领域摩擦一万小时，就想成为专家，这种想法根本就是在对自己耍流氓。
待世人发现自己投入大量时间金钱学完，仍旧不能运用自如的时候，就给自己贴了个标签 —— 没天赋
很多人认为我写报告很好看，我做的幻灯片简约且有商务范儿，说是我有天赋。而我曾经也经常琢磨报告到夜里两三点，还研究苹果、小米这种企业的发布会幻灯片，加上我少年时以画画为爱好，所以你说全部靠天赋，我自己是不接受的。
曾在上海学习韩语的时候，被老师和同学夸赞发音很赞，与韩人无异，也被称为天赋。可我当时是连刷牙的时候都在练习发音，一度觉得自己下巴脱臼，这些都是大家看不到的，当然，年少时我唱歌很喜欢研究发音，这一点一般人我也不告诉他。
所以这些玩意儿，你说算不算天赋？喜欢就算天赋，不喜欢只能算负担。
格拉德威尔的一万小时一定是自己喜欢，且与自己人生轨迹匹配的一万小时，才能练就专家技能。
但有了专家技能还不一定能成就自己，得看机遇。
比如我从事多年的软件质量保障工作，那我又不是那种只喜欢通过技术手段去解决问题的人，很看重流程和规范。作为曾同时拥有 PMP 和 ScrumMaster 双项认证（实话实说，续费了几次之后就停止续费了，现在证书已过期）的我，在研发 DevOps 协作平台的产品团队待了两年，突然 DevOps 这概念还火得一塌糊涂。市场上讲理论的多、能落地的少，而我更喜欢落地和解决方案，还偏偏喜欢倒腾数据，倒腾指标，巧了。
真分享
能听我哔哔到现在的朋友，我权当是真爱了，所以也不好意思啥都不分享。
简单分享一个上线之后回滚的事故，是的，确实是事故。咱么不教学，只介绍一下情况，毕竟家家有本不同的经，成功的案例不可复制，失败的案例只做领悟。
事故是这个样子的：
话说有一天，用户发现了产品使用页面上的一个错误，提出需要修改，修复很简单，一行代码的事儿。产品采用微服务架构，最终只要替换前端服务即可，用户可以无感知。
测试团队由于没有多余的环境来验证代码修复，加上开发提供的信息是“只修复了这个问题，其他没改”，因此全队一致认同直接上线，上线后测试团队赶紧去验证了一下修复，结论：修复成功
本来皆大欢喜，但现实很残酷，没多久，就发现使用其他功能的时候，页面上一堆堆的红色报警。
经过一番排查：前后端不兼容
WHAT? 修了一个前端错误，就前后端不兼容？
深入确认得知：此时的开发团队还没有引入代码分支管理和版本管理，开发的代码中早已经找不到线上版本了，不仅找不到，还已经参杂了非常多的没有测试过的功能。而开发同学所说的“只修复了这个问题，其他没改”是针对他的开发环境，而非生产环境。
这种情况下，没人能评估这种不兼容带来的影响有多大，无奈，只得做出回滚的决策。
事故的来龙去脉其实很简单，但影响不太好。无巧不成书，客户就在我们升级后的那一会会儿，难掩缺陷修复后的惊喜，但紧接着我们的回滚，直接打脸，惊喜没了，没办法，自己翻的车，总要找个理由。
你发现了吗？最大的风险并不是技术强弱，而是缺乏流程和规范。
很多翻车现场并不是技术问题，技术问题顶多算技术债，而没有流程和规范则是放任风险，终有一天会成为事故，别人口中的故事。
一点心得
这起事故的最大作用在于，让大家认识到了流程和规范的重要性，是值得大家去遵循的。
毕竟，风险是可预警可防备的，而翻车成了事故，解决得再好也像打了补丁。
我是石巍（Will），资深软件质量工程师、DevOps 落地专家，专注于为各类中小微企业提供接地气的 DevOps 解决方案。