产品经理反馈海外某地工厂停工,原因是产线有道环节是设备开机上传key至加密机。经与研发沟通后,链路:客户-CDN-源站api-上海机房加密机。头天凌晨2点出的问题,销售同学帮挡了一道。
第二天上班看了源站日志,下意识以为CDN问题,更换两次节点后,客户反馈仍有问题,视频里桌子上一排商米设备,国内15秒激活,这里要1分钟,还有超时。客户的极度不配合加上已经是半夜1点,群里的产品经理不断催促、强调问题严重性,心烦意乱,还要和他battle。
查看日志,没一条非200的。判断用户网络到CDN间的问题,直接去掉CDN回源

事后产品追着大家要长短解,
我:缩短网络距离,智能解析切换CDN、激活服务就近部署
深圳研发:传key动作后置,不在生产环节做,牺牲一部分设备掌控性
大家畅所欲言时,被批评 “不专业、开会效率低,应该只提痛点,专业的事交给专业的人,不要替其他人做决定!”
CTO:加密机批量生成sn、key对应关系,保存在当地IDC,异步申请key,不再怕弱网、间歇被墙

高下立判,我深陷“知识的诅咒”,完全从自己的视角出发;研发多少带了业务场景,用较低的售后成本避开问题;CTO则结合了技术与业务,创新性的引入“异步前置仓”

优势:
对网络轻车熟路,日志、变量因素,发现多项关键线索,快速定位

反思:
容易被情绪左右,对待“刷存在感”的同学不能无视
还是缺乏系统性思考,只能站在技术的狭小角度

业务镜像往往是非常精简、基础(处于安全考虑也不应该安装非业务内容)。不含常见的curl、ping、tcping、tcpdump等工具,甚至没有sh,kubectl-debug太重,需要在node安装agent,有更简单的方法:nsenter,是大多数系统自带的用于进入指定命令空间的工具。

#查看容器位置
kubectl get pod xxx -n xxx -o wide

2021-09-14T02:02:42.png

#在容器所在物理机查看容器id
docker ps |grep nginx-new-57f8fcdc7d-6r69n
#容器内查看Pid
docker inspect c5decf942415|grep -w Pid

2021-09-14T02:02:58.png
2021-09-14T02:03:08.png

#nsenter进入,此时和容器处于相同进程空间,可以使用宿主机的所有命令
nsenter -n -t 87296 #可以看到只能看到容器本身IP

2021-09-14T02:03:23.png

#从抓包内容验证,只有访问此container ip的请求才能被抓到
#使用完成记得ctrl+d退出

image.png

混沌工程(Chaos Engineering)到底是啥?

现实世界比demo更复杂,系统的正常运行需要网络、存储、虚拟化层、OS、中间件、数据、应用的多项配合,每天都会遇到各式各样的故障,这些真实世界的故障信息就是最好的混沌工程变量。
我认为的混沌工程,和安全领域的零信任颇为类似,无论处于网络边界之内或之外,都不应该自动信任任何事务。任何组件都有发生故障的可能。

混沌工程是测试工作的超集,虽然混沌工程和传统测试通常会有很多共性,比如都使用“错误注入故障注入”,测试是使用测试工具都某块进行测试,混沌工程更像实验,通过不断模拟故障,观察系统的”反应”,追求在真实环境中演练。
在真实世界中,常见的故障:
硬件,硬盘老化、电源掉电、内存ECC等
网络,延迟、丢包、阻断等
系统,资源耗尽、内核bug等
拜占庭错误,集群脑裂、影响选举制度等
上下游服务故障,比如三方接口故障、服务循环依赖等

没必要对所有的风险点进行测试,要考虑故障比例,把较为频繁的故障列为第一优先级。比如没必要测试内网间的延时、OSS的文件损坏、SLB的转发失效等,应该模拟自身服务调用延迟、依赖厂商的支付接口、外部被墙等,这样的模拟是非常有效果。

接下来是争议最大的部分,混沌工程追求在生产环境模拟,大部分厂商是没魄力的,传说网飞就很猛,有自信直接停掉aws的一个可用区(个人觉得夸张)。常见的做法是录制线上流量,成倍数、倍速回放到测试环境、或者在金丝雀环境。失效也仅影响一小部分用户。btw,阿里云的AHAS年初已经正式版,全自动的故障模拟,包装了大部分复杂度👍🏻

给自己定个OKR,下半年把以往做过的故障注入、流量管理串起来形成文字💪🏻

回顾近期的一些想法
1.“挖洞有奖”,提供入口给外部黑客报告bug,提供奖励
公司没有投入安全,应该是要等到故障后才能重视,投入。
大厂都有挖洞有奖,下面链接是谷歌在过去10年,它一共向11,055个软件漏洞,支付了29,357,516美元的奖金,平均每个漏洞2656美元(约1.8万元人民币),共有84个国家的2,022名程序员拿到奖励。
这其实非常划算,一年费用不到300万美元,就能发现1000多个漏洞。如果其中任何一个漏洞被人利用,对谷歌造成的损失,可能都远远大于这个数字。
这就是为什么大型软件公司都悬赏开发者,向它报告软件漏洞。
https://security.googleblog.com/2021/07/a-new-chapter-for-googles-vulnerability.html
2.对部门的教育激励,属于公司首例,申请了8K的培训经费。用于购买书籍,考试通过发放现金奖励
3.内部钓鱼系统,由IT同学发送🎣邮件,看谁中招
4.IT监控大屏

在商米也两年了,运维工作也理顺了。随着接手IT部,责任和压力一并来了。
前几个月,更新过一波猎聘(纯纯个人习惯,并不是干的不开心),简历也一直处于“不找工作”状态。有几个猎头还是推荐了几个有意思的职位,记录一下
一.初创公司运维负责人,组建团队,汇报对象CTO。
对运维的理解,怎么做运维体系,CTO对运维系统执念颇深。我从业务层和他讲起,大意是运维不能只做基础的维护工作,也没有一招鲜式的银弹。我对初创公司搞运维系统持反对意见。
1.初创期间,我们图快,这时候更应该走敏捷提高效率,CICD上多花点心思,让大家的编码能够尽快可能流畅的上线
2.指定符合当前的规范,比如根据业务天然分库,使用各自独立的库账号,分支规范、配置中心、监控等
头开好再去搞体系化,当然前两条也属于。搞更加深入的体系化
最终CTO认为对他公司意向性不强。无下文了
总结:时长40分钟,准备不够充分,紧张,表达不够简练,啰嗦

二.猪厂,近期没落了,某游戏块的运维负责人
问题大同小异,同样没怎么问技术问题,可能我的简历偏技术,没空话套话黑话。问了些容器、网格的问题,分享了几个典型的排错场景,从沟通来看,对方起码这块的技术是缺失的。问了些管理类、当前的优劣势,面试官是此项目负责人。态度亲切
总结:视频面一小时,仍然有点“怯场”,可能习惯了大厂的光环。觉得大厂如何如何牛逼。同样,发挥一般,自身的亮点没讲出来

三.鹅厂,云原生架构师,不涉及管理,有点像运维专家、顾问类,干活,解决难题的
这次就非常正规了
1.一面视频面,应该是同组的人,估计没看我简历,问了些怎么确保在跨云迁移中数据一致性问题,包含mysql、redis,这块我没答好。容器网格技术初级,没问到什么关键点。全程我开视频,看对方没开,感觉有点不爽,半小时结束。 结束后我还小吐槽一波“明显没看我简历,jd中提到的容器简单问了两项,感觉没受到尊重”给猎头
2.没想到第二天受到了通过短信,深圳的号码约我二面,很快收到短信,还是视频面,都约的很晚。这次的同学主要给我讲了工作内容,不过我没太听进去,琢磨问题去了。简单问了我卖课的经历。面试时间也很快 半小时。我直接问,你觉得我有哪些不足的地方,对方回:“你太想知道答案了”,结束
3.心里是有感觉的,马上收到了“通道面试”邀请,这次的面试官更像研发,追问了一些容器和具体排错案例,我已经明显放开了,准备的也更充分了,好像讲述职一样,洋洋洒洒聊了一小时(PS:这位同学迟到很久,不断的道歉说互联网人要理解,有个紧急的会议冲突了,让我来了也有个心理准备,要加班到很晚- -,我在想和我个面试者说这个不怕吓走吗)由于我已经说的放飞自我,基本没啥问题能难得住我了。面试官必须得上hard了,
“父进程和子进程读取的内存内容是否一致?” 直言不会
“简述tcp3次握手过程?” 大概记得,描述个大概
“1亿个乱序整数,怎么最快取最小的前100个?” 就知道排序有个分治法,切分成很多组。当然我不是研发,这块没深究,就说不会了
确认是研发同学了,当然面试官必须不能让面试者全答对,表示理解
4.收到终面邀请,主动开视频的,我也开了,就十分钟,应该是这条线的leader,问了我为啥两年一换,我也直言,感觉没挑战,坑排完了,薪资没跟上。说我太简略。我还是围绕这个展开,一共10来分钟
如果过,可能有hr来聊薪资,不过就当历练。偶尔被猎头推着面试也是个锻炼过程,未完待续

update:收到offer,职级比预期的低,但总包的薪酬还可以。最终各种原因,当前的领导对我还是很信任。婉拒

作为一个从事运维工作十多年的“行业老人”,深感技术的进步是令人激动的,甚至惶恐的。从传统自建机房、配置基础服务、网络,拥抱开源,到2014年云厂商发力,其中阿里云一年经历6次降价,哪怕当时的云厂商稳定性堪忧,彻底使“上云”成了主旋律。革了传统运维的命,淘汰掉一批底层技术人员。技术“耐久度”越来越短,近期的云原生、AI、大数据技术,使运维能从传统运维到当下的业务运维再到数字化运维,从而不断探索运维的的价值。

转型一、运维的研发化。让运维人员进行研发,人创造机器,再由机器取代人来做维护,这个落地就是DevOps,基于显性化的运维能力,各个专业领域都要自治。

转型二、运营的数字化。从故障的发现、定位到处置操作,要做到感知的泛在化、认知的智能化和操作的无人化(这就是AIOps的落地)。

  • 手动时代,标准化 弊端:人手一套脚本,功能单一,无法传承,无法应对大规模
  • 自动化时代,逐步成体系,沉淀出部分方法论,可能有运维系统,DevOps、ChatOps逐步落地,有着仅适用于本企业的运维系统。把人训练为机器
  • 智能时代?

聊AIOps前,包括我自己,都有困惑。把机器训练成人,再淘汰掉人?

    - AIOps是不是伪命题、炒概念,

    - “有人说运维转型势在必行,技术、规模升维带来的问题和挑战只能用技术能力发展解决,一定要用机器解决机器的问题”

    - “很难形成体系的AiOps‘银弹’,最大的问题,训练数据源”

    - “AIOps 的核心主要集中在数据算法、机器学习技术方面。不止运维专家要了解业务架构,负责平台研发,决策分析的闭环执行;更需要AI算法专家对比方、层次聚类、随机森林、时序数据分解、DNN、RNN 等算法方面的技能,所以一个完整的 AIOps 实践需要多团队 & 技能协同运营等相关多维度能力要求。一个完整的 AIOps team 会是需要一个多方面综合技术能力的集中“


企业转型AIOps,对”顶端“以下的运维伙伴都会带来致命冲击,配置变更、环境部署升级、性能分析、troubleshooting,可以被分析、处理、治愈、训练,以前只有人能做的”决策“动作也会被机器算法取代。我们不是在想象《黑客帝国》中的剧情,AI已在围棋、星际争霸大幅领先人类。趋势就是这样,我相信在短时间内,AI只能呈现选项供人决策,不断学习后最终自己完成闭环。

关键字:混沌

想解决某台服务器的安全问题,却触发了以往的配置的bug,导致生产事故,被追责。执行人觉得很冤枉。

这个世界的运行,并不是最优状态,只是在各种因素下产生的平衡,这本身也是种”精妙”的设计。这时,“局部”的对策比问题本身更糟糕。

要能理解、认同这一状态

这时,就要引入系统性思考了,那什么是系统性思考

站在高点,看见整体。当你站在地面时发现有河流、山丘、峡谷,坑洼不平,当你在大气层以外,发现地球已经变成光滑的球体。做技术,不能只做技术

理清关系,我们要看的,不只是系统中的元素,更要理解其中的关系。比如一个常见的例子,小公司往往发展到一定阶段,想要引入大厂高P同学,妄图用飞机引擎带动一辆汽车。没有理解,高P同学只有在大厂这个完整的体系下才能发挥作用,要把目光拉到一个整体,从系统的角度去改善

系统性思维是一种变化的视角。你所做的每件事,都在持续影响结果,而且是多个结果。比如你努力工作,得到晋升,薪资职级得到调整,面临更大责任,不得不利用加班时间学习,陪伴家人的时间减少,导致妻子对你心生不满,你却觉得冤枉,家庭关系出现矛盾,幸福感反而下降


前两天看到个段子,怎么区分一个运维同学是否资深。普通运维接到需求时:”很简单,直接用A方法,半天搞定”

资深运维:“为什么这么做,需求上下文都告诉我。这事我预计有ABCDE这五个变量,还不包含未知变量,结合我手头的优先级,一周时间。并且其他方法有”
未完