专业人士要终身学习：职业发展是一场马拉松，而非百米冲刺。在知识半衰期不断缩短的今天，停止学习就意味着贬值；专业人士必须建立“输入-消化-输出”的学习闭环，通过阅读、培训与实践，不断更新认知体系，确保自己始终站在行业潮头，而非被时代淘汰。

专业人士要有技术敏锐性：不仅要低头拉车，更要抬头看路。这意味着要时刻关注技术风向标，洞察新兴技术的成熟度和商业潜力，从而在技术选型、架构演进上做出前瞻性决策，避免在错误的技术栈上投入沉没成本，错失转型良机。

专业人士要有技术纵深：广度决定下限，深度决定上限。在核心专业领域，不能满足于“会用”，必须深挖底层原理、源码逻辑与架构思想，构建起深厚的“护城河”；这种解决复杂难题的能力，是在激烈竞争中不可替代的核心资产。

专业人士要有行业纵深：技术是工具，解决问题才是目的。脱离业务的技术是无本之木，专业人士必须深入理解所在行业的产业链条、商业模式及痛点，让技术方案精准匹配业务需求，实现从“技术实现者”到“业务赋能者”的角色跃迁。

专业人士要主动思考价值：工作不等于价值，忙碌不等于产出。在执行任务前，要先思考该任务对公司的营收、成本或效率有何具体贡献；只有将个人工作锚定在业务价值上，才能分清轻重缓急，确保每一份努力都能转化为可见的成果。

专业人士要主动规划未来：不要用战术上的勤奋掩盖战略上的懒惰。要定期评估行业趋势与个人优劣势，制定清晰的3-5年职业规划，并有针对性地补齐能力短板；拒绝做“提线木偶”，掌控自己的职业节奏，才能在不确定性中把握主动权。

专业人士要主动复盘：没有复盘，经历就只是经过。通过定期的“复盘会”，客观分析成功的关键要素与失败的深层原因，将感性的经验提炼为理性的方法论；这不仅能避免重复犯错，更能形成螺旋上升的成长曲线，加速能力进化。

专业人士要主动管理时间：时间是最公平的稀缺资源。要学会运用“四象限法则”等工具，将精力聚焦于高价值、高回报的重要事务上，坚决摒弃伪勤奋和低效加班；通过合理的授权与拒绝，确保关键目标得到充分的资源投入。

专业人士要保持身体健康：健康是1，财富和声望是后面的0。高强度的工作压力需要有充沛的体能作为支撑，规律的作息、科学的饮食和持续的锻炼，不仅是为了防病，更是为了保持大脑清醒和情绪稳定，支撑长期的职业长跑。

专业人士要做事靠谱：靠谱是职场最高级的社交货币。它体现在“凡事有交代，件件有着落，事事有回音”的闭环思维中；交付结果时要多想一步，遇到困难要提前预警，这种确定性能让团队和组织对你产生极高的信任依赖。

大环境不好，怎么办：寒冬之下，剩者为王。首先要守住现金流，降低杠杆，保持财务韧性；其次要回归本质，打磨核心技能，成为团队中不可或缺的人；最后要保持韧性，将低谷期视为沉淀期，在别人躺平时积蓄力量，静待春暖花开时的爆发。

2024年12月：OpenAI故障
事件经过：12月11日，OpenAI发生故障，影响依赖其服务的用户及企业。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰AI相关业务及研发工作。

2024年11月：华为云华南地域部分服务异常
事件经过：因网络设备升级失误，导致华为云华南地域部分云服务访问异常，持续约2小时。
事故原因：内部设备升级操作失误。
造成损失：客户业务短暂中断，华为云快速修复并致歉。

2024年11月：支付宝交易故障
事件经过：11月11日，支付宝发生交易故障，影响用户支付及交易行为。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰用户日常支付及商业交易。

2024年11月：Snowflake云服务逻辑故障
事件经过：11月，云数据平台Snowflake发生严重的服务中断，持续长达13小时。
事故原因：软件更新引发的逻辑冲突。软件更新引入了向后不兼容的数据库架构更新，导致版本不匹配错误。更糟糕的是，其“区域冗余”机制在逻辑故障面前失效，导致10个区域同时瘫痪。
造成损失：大量企业无法执行数据查询，暴露了云服务在面对“逻辑层面”故障时，物理冗余机制可能完全失效的风险。

2024年9月：甲骨文云基础设施故障
事件经过：甲骨文云某区域存储系统故障，导致部分客户数据无法访问，持续超6小时。
事故原因：存储系统运维故障。
造成损失：客户业务中断，甲骨文面临索赔，声誉下滑。

2024年9月：阿里云新加坡数据中心火灾
事件经过：9月10日上午，阿里云新加坡可用区C数据中心发生火灾，导致17项服务异常，Lazada、字节跳动等业务中断。
事故原因：锂电池起火引发故障。
造成损失：多家企业业务中断，阿里云海外服务稳定性受质疑。

2024年9月：上交所交易故障
事件经过：9月27日，上海证券交易所发生交易故障，影响证券交易正常开展。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰资本市场交易秩序。

2024年8月：网易云音乐故障
事件经过：8月19日，网易云音乐发生故障，排查耗时近2小时后恢复。
事故原因：疑似与云存储扩容、贵州机房迁移相关，官方未披露确切原因。
造成损失：用户无法正常使用音乐服务，平台用户体验受影响。

2024年8月：上海电信城域网设备故障
事件经过：8月26日，上海电信城域网设备发生故障，影响区域网络服务。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰民众网络使用及商业活动。

2024年7月：微软系统蓝屏事件
事件经过：7月19日，使用了Windows操作系统的设备大面积蓝屏，导致850万设备受到影响。
事故原因：微软安全供应商CrowdStrike推送了错误的软件配置。
造成损失：成为2024年主要信息系统故障之一，对大量用户工作及使用造成影响。

2024年7月：阿里云故障
事件经过：7月2日，阿里云发生故障，具体影响范围覆盖多款服务。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，影响依赖阿里云服务的客户业务。

2024年4月：腾讯云控制台故障
事件经过：4月8日15点23分，腾讯云云API服务异常，导致云函数、文字识别等依赖服务无法使用，持续87分钟，1957个客户报障。
事故原因：配置数据错误，经紧急数据修复恢复服务。
造成损失：影响客户业务正常开展，平台服务可靠性受质疑。

在各项目组努力下，终于达成了几个目标：
1、springboot升级到2.x
2、干掉了老技术中台，全部系统对接到新技术中台，实现了技术中台统一
3、填了一波史前巨坑

今年希望达到几个目标
1、科技降本600万
2、升级k8s到1.20
3、如果时间来得及，实现动态扩缩容
4、日常，继续填历史的技术坑

1、redis调优
数据流：
数据库查询结果-》缓存到redis-》缓存使用者
表现：
bigkey一大堆，单个key存放数据3M多（你咋不把整个JVM塞到redis里去呢），redis服务器所需内存、带宽都特别高
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、改变序列化方式，从jvm序列化，调整为protobuff，调整后，带宽瞬间大幅下降
b、减少序列化的数据内容，只保存真正需要的，调整后，redis内存大幅下架，带宽大幅下降
c、对redis进行拆分，将一个大redis，按领域拆分为多个小redis，性能提升明显
d、对于热数据不明显的低频访问场景，不缓存到redis，大家慢慢优化去吧

2、网关调优
数据流：
外网请求-》外网网关-》外网鉴权-》内网转发-》内网网关-》内网鉴权
表现：
外网网关和内网网关功能一样，而且逻辑超级复杂，性能垃圾的一塌糊涂
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、干掉外网网关鉴权内容
b、增加外网网关黑名单过滤、访问频率限制等功能
c、外网网关性能大幅提升

3、数据流优化
数据流（大幅简化后）：
C系统-》数据中台-》逻辑加工-》H系统
Y系统-》数据中台-》逻辑加工-》H系统
H系统-》数据中台-》逻辑加工-》C系统
C系统-》数据中台-》逻辑加工-》H系统
H系统-》F系统
表现：
业务逻辑分散到各业务系统，数据来回传递多次，多个系统加工同一批数据，一旦出问题，要多个系统联查，花费很长时间才能定位到问题
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
C系统-》Y系统-》H系统-》逻辑加工-》F系统
C系统-》数据中台
Y系统-》数据中台
H系统-》数据中台
在哪个环节出了问题十分清晰，用户自己都能初步定位到问题

4、数据修改请求超级多
数据流：
问题1、问题2、、、问题X-》老子就要修改数据-》提工单
表现：
数据质量差，任务都给到了IT，管理方没有管理动力，数据质量持续差，修改量逐年上升
原因：
分析后发现，各业务条线管控要求很多，不放权，与各地执行机构有轻度脱节
数据生产者，不承担数据质量差的职责，没有提升数据质量动力
总部管理部门，不承担数据质量差的职责，不清楚数据质量哪里差，没有工作重点
解决：
a、分析数据修改工单，归纳前几类修改请求
b、与业务方沟通，对分支机构可以修改的数据，将功能开放给各分支结构，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
c、对于分支结构不可以修改的，开放数据修改功能给总部管理部门，进行统一管控，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
d、数据质量与考核挂钩
e、数据质量快速提升，工单量大幅下降

5、降本
数据流：
应集团要求，降本压力巨大，科技承接了600万降本指标
表现：
科技方压力山大
原因：
一开始几年，没有这么大的压力，大家手都比较松，各条线都存在较大浪费，科技也是如此
最近几年，都是在之前资源上，不断的挤压资源，来满足每年业务快速增长的需要
今年，一方面业务继续快速增加，另一方面要大幅降本，压力山大
解决：
a、第一轮，运维小伙伴拉流量，无流量服务应关尽关，应下尽下，应合尽合
b、第二轮，运维小伙伴拉各类峰值，先统一砍一刀（网络、数据库、主机）
c、第三轮，运维小伙伴看账单，按账单大头，如网络、数据库、主机等逐条应用降本方案
d、第四轮，运维小伙伴看账单，对于不合理的条目逐条检视，逐个逐个扣
e、第五轮，各项目组，结合业务实际情况，各自制定降本方案，限时落地
f、第六轮，技术委员会，对于20%的关键业务进行性能优化，逐步降本
g、第七轮，在运维小伙伴推动下，实现自动扩缩容，继续降本

1、更换服务器后，出现网络风暴
表现：
老服务器下架，新服务器上线后，出现网络风暴

原因：
逐步排查网口，猜测一根光纤出现问题

解决：
更换了一根光纤

2、老服务器下架后，新服务器重启后，VM集群无法启动
表现：
三台ESXI主机组了VSAN，重启后，网络互通，但服务器2被独立，无法加入1、3集群
VCSA也在VSAN上，同样无法启动。

原因：
故障时，只知道出现了脑裂，三台主机无法

解决：
重启了VPXA、重启了ESXI，没有解决问题
重建VSAN，然后把三个节点加入，问题就修复了
后续发现，其实时服务器1和服务器3出现了问题，自己组成了一个新的集群

2023年12月：谷歌云新加坡区域故障
事件经过：因网络配置错误，导致谷歌云新加坡区域服务中断超3小时，影响大量企业客户。
事故原因：内部网络配置失误。
造成损失：客户业务中断，谷歌云赔付客户，市场竞争力受影响。

2023年11月：阿里云全线产品故障
事件经过：11月12日下午，阿里产品全线崩溃，波及全球多个地域全部云用户，持续事件达3.5小时。
事故原因：具说是鉴权服务出了问题。
造成损失：凸显云计算集中化部署风险，影响全球多地客户业务。
小插曲：两周后，在2023年11月27日，阿里云再次遭遇了近两小时的中断，影响到中国和美国的客户。然后当天晚上，滴滴就来了个大的。

2023年11月：滴滴崩溃
事件经过：11月27日晚间，滴滴崩溃，致APP地图无法加载、无法叫车，持续约12小时，影响多地用户。
事故原因：底层系统软件故障。
造成损失：订单流失，品牌形象和用户信任度下降。

2023年10月：新加坡Equinix数据中心制冷故障
事件经过：新加坡Equinix数据中心承包商误关闭冷冻水阀门，导致制冷系统误操作，造成2.5万笔银行交易失败、8.1万次登录失败。
事故原因：承包商操作失误，误关冷冻水阀门。
造成损失：金融交易及用户登录受严重影响，暴露运维管理漏洞。

2023年10月：语雀重大服务故障
事件经过：10月23日14时左右，语雀发生重大服务中断，在线文档和官网无法访问，当晚22时完全恢复，持续近8小时。
事故原因：内部运维工具缺陷，新上线升级工具bug导致华东生产环境存储服务器误下线，造成大面积服务中断。
造成损失：定性为P0级重大事故，影响数千万用户工作与知识管理，引发对运维自动化工具安全性的反思。

2023年6月：中国电信广东网络故障
事件经过：6月8日中国电信广东区域遭遇大规模网络服务中断，用户普遍无信号、无法通话上网，故障约4小时后恢复。
事故原因：网络设备故障。
造成损失：影响广东省内商务活动和民众生活，具体损失数据未公布。

2023年5月：苹果iCloud全球服务中断
事件经过：5月11日，苹果全球服务遭遇“史诗级”宕机，持续约55分钟。大量用户的Apple ID突然登出，无法访问iCloud照片、文件和备忘录等关键数据。
事故原因：数据中心严重故障。虽然苹果未详细披露，但此类核心服务中断通常源于数据中心底层存储或认证服务的配置错误或硬件集群故障。
造成损失：数千万苹果用户数据访问受阻，打破了苹果生态“稳定可靠”的神话，引发了对苹果云服务能力的广泛质疑。

2023年5月：微软Azure故障
事件经过：5月24日，微软Azure DevOps在巴西的一处scale-unit发生故障，导致宕机约10.5个小时。
事故原因：导致该中断的原因为一个简单的拼写错误，最终导致17个生产级数据库被删除。
造成损失：大量用户无法使用云服务。

2023年4月：中信证券APP交易阻塞
事件经过：4月期间，中信证券APP出现严重的交易阻塞现象，客户无法正常下单或撤单。
事故原因：系统软件缺陷与容量规划不足。在市场交易活跃期，系统未能有效处理高并发请求，暴露出软件逻辑缺陷和灾备能力的不足。
造成损失：直接影响客户交易，导致客户资金错失交易时机，引发大量客户投诉，对券商的声誉造成了直接的负面影响。

2023年3月：推特全球大规模宕机
事件经过：平台代码更新错误，导致全球用户无法登录或使用推特功能，持续超5小时。
事故原因：内部代码更新失误。
造成损失：用户体验差，广告收入受损，平台声誉下滑。

2023年3月：广州某电信机房制冷故障
事件经过：广州某电信机房水冷系统破裂引发制冷故障，微信、QQ及政务云系统瘫痪，机房被迫采用冰块临时降温。
事故原因：水冷系统破裂，制冷功能失效。
造成损失：国民级应用及政务服务中断，影响范围广、社会影响大。

2023年3月：腾讯云机房事故
事件经过：23年3月29日凌晨，腾讯云广州五区部分云服务异常，导致微信、QQ、支付等核心功能受到影响，故障在当天中午基本恢复。
事故原因：官方反馈为“本次事故由广州电信机房冷却系统故障导致”。
造成损失：核心应用不可用。

2023年3月：B站双重崩溃
事件经过：2023年B站经历了两次较为严重的全站级宕机。一次是3月5日，用户无法访问视频详情页、收藏夹；另一次是8月4日，视频封面无法加载、视频缓冲失败。
事故原因：底层服务依赖故障与机房电力问题。虽然具体细节未完全公开，但此类大型视频平台的崩溃通常源于核心微服务依赖失效或机房电力/网络架构的单点故障。
造成损失：数亿用户无法正常观看视频，严重影响用户体验和社区活跃度，尤其在流量高峰期的崩溃对品牌形象损害较大。

2023年3月：唯品会P0级宕机事故
事件经过：3月29日凌晨00:14至中午12:01，唯品会南沙IDC冷冻系统故障，机房温度骤升导致大规模宕机，线上商城停服12小时。
事故原因：制冷设备故障。
造成损失：影响800万人次客户，直接业绩损失超亿元，定性为最高级别P0级故障。
小插曲：事故后，对基础平台部负责人予以免职。

2023年2月：甲骨文多日长故障
事件经过：2月13日至15日，甲骨文云基础设施（OCI）遭遇持续长达数天的服务中断，这是OCI历史上罕见的长时间故障。同时，其子公司NetSuite也因关联故障停摆。
事故原因：DNS后端基础设施性能问题。支持OCI公共域名系统的后端API基础设施出现性能瓶颈，导致无法处理传入的服务请求；此外，NetSuite的故障还叠加了合作伙伴数据中心（Cyxtera）的物理电力故障。
造成损失：客户业务连续数天无法使用云资源，甲骨文“永不宕机”的宣传口号受挫，大量依赖其数据库服务的企业陷入停滞。

2023年1月：美国民航系统瘫痪
事件经过：1月11日美国联邦航空管理局飞行任务通知系统因关键文件损坏瘫痪，备份系统也检测到相同损坏，重启系统导致全美航班禁飞。
事故原因：系统文件损坏。
造成损失：超4000架次航班延误，698架次取消，数十万旅客受阻，经济损失巨大，暴露单点故障风险。

咱们做技术的人，都喜欢起名字：信息化、数字化、数字平台、数字化转型、数智平台等，让很多人一开始觉得好高大上，然后又开始发懵，这些词之间有什么区别呢？试着通俗解释一下：

1、信息化
把组织线下业务流程，放到线上的过程。
比如，咱们学校上线了考勤系统、选课系统，这就是一个信息化的过程

2、数字化赋能阶段一：数字报表
在信息化的过程中，产生了部分的数据，对这部分数据进行挖掘提炼，得到一些报表，对组织经营起到了一定的提升作用。
比如，大家经常能看到的各类系统报表，通过经营分析报表，指导管理经营行为。

3、数字化赋能阶段二：数字平台
信息化建设后，各个系统之间是割裂的，各系统之间数据是互不相通的。
如何将数据打通，让组织运营者，可以对企业状况一览无余。
比如各类数据平台项目、数字平台项目，一般都会为运营者提供各类“驾驶舱”或Dashboard。
其实就是为管理者开了天眼，有了全局视角。

4、数字化赋能阶段三：自动化平台
当企业数字化建设到一定程度的时候，很多管理规则可以抽象并固化为系统规则，不需要人干预即可处理事情。
比如自动化制造、自动化质控、自动化风控、甚至量化交易等等。

5、数字化赋能阶段四：智能数字化平台，或数智平台
在3的基础上，引入了一些物联网技术、智能终端技术等，一方面让运营者可以快速感知一线情况，一方面可以快速决策反馈。
比如电商平台发现交易异常的时候，会触发智能平台的规则，自动止血；或者一些智能可穿戴设备，实时监控患者病情，及时进行干预。

6、数字化转型
但组织到了一定的发展阶段，传统的运营方式，已经无法支撑组织进一步的快速发展。
需要自上而下的去调整思路，用数字化运营的方式，重塑组织的运营方式，这其中数字化技术只是一个手段。
以华为为例，他们建立了基础IT架构（华为云），打造了统一的数据底座，提供了统一的数字服务，使用了大数据、AI、IoT等技术，最终通过数字化重构了业务运营方式，包括数字化作业、数字化交易、数字化运营、数字化办公等，从而造就了了华为近10年的飞速发展。
对于咱们老年人慢病管理，我们同样需要技术架构，同样需要统一的数据底座，同样需要封装统一的数字服务，同样可以使用大数据、AI、IoT等技术，但最终要重构哪些业务的运营方式，要重构成什么样子，就是咱们课题组要考虑的了。
比如，我们通过数据分析，可以主动为各类患者提供各类服务（比如糖尿病患者），比如：量身定制适合各自的治疗及追踪方式，量身匹配到不同的家庭医生，提前把患者需要的药帮患者准备好，提前把社区医院的耗材准备好等等等等。

7、数字化赋能与数字化转型的区别
7.1、数字化赋能
业务V1.0+数字技术=》业务A V1.1
7.2、数字化转型
业务 V1.0+自上而下的数字化运营体系+技术体系支持=》业务 V2.0