根本不是什么病, 你所有的顾虑都来自于你并非医疗专业人士, 又能轻易获得一些医疗材料.

上面那三点, 第一点要常做, 第二点等机会, 第三点等时间.
会好的.

事后多思索自我,
还需要等一点机会(比方: 某天因为自己情绪问题, 造成了 一些或大或小的不可挽回的影响),
还需要年龄再大一些.

满足这几个条件, 你这个情绪问题大概率就能好了.

@hongyexiaoqing

个人认为, DevOps 并不一定就要自己研发相关系统, 毕竟大部分公司关注的是公司层面的业务系统, 所以至于 DevOps team 是使用的自研系统还是广泛使用的系统, 从管理层看是不太 care 的.

能自己开发给其它 DevOps 使用的系统自然是高级 DevOps 能力的体现.

但楼主更关注的是如何开始 DevOps 方向, 而不是 DevOps 这个方向的高点在哪里.

@YaakovZiv

这是那个 Team 就没有太按照 DevOps 的方式来运作吧, 他还有很重的之前 Ops 的思路.

否则以代码驱动的配置, 是一定会走 git 的, 再有个一般性的 review, 被同意再进行 修改配置代码的部署.

直接上去改配置绝对是 DevOps 的大忌讳, 因为会导致实际环境和代码部署的环境不一致.

前面说了不同规模的公司, 运维所具体的工作内容和具体的技术栈差别很大.
我尝试理下 DevOps 所需要的: 基础的大方向, 这些应该和公司规模及技术栈没太多关系.

硬的:
1. 一个操作系统方向[Linux/Windows]
2. 一门脚本语言 [Shell/PowerShell]
3. 一个业务开发语言[Java/Python...]
4. 一个配置管理工具[Ansible/Chef/Salt ...]
5. 一个基础设施即代码工具[Terraform, Cloudformation, CDK 等]
6. 一个公有云平台/一个私有云平台/一个容器化平台
7. 一个 CI/CD 平台
8. 一个监控系统的应用
9. 一个日志系统的应用
10. 一个备份管理系统的应用

软的:
11. 一些网络知识
12. 一些安全知识
13. 一些业务连续性知识
14. 一些业务系统运作的架构知识
15. 一些各层面所需的测试工具和知识
16. 现代应用和基础设施 部署和管理的一些思路和思想[基础设施即代码 IaC, 容器化, 应用发布模式 ... ] [对这些的理解会直接影响如何应用具体技术进行工作].

我就先想到这些.其他朋友再补充.
而且, 这其中每一条应该都可以展开为一个知识/技能体系.

上 Dev Container 可能是你的最终方案吧
行业里也都是这么做的.

否则一个操作系统环境 终归容易出问题

看起来确实很棒, 以这个项目, 应该足够教人学会 Next.js 了

@justdoit123

Jenkins 里的 secret 管理确实不是很好的选择, 但也胜过记录"加密"过的密码在代码里, 再在 pipeline 里"解密". 这种方式实质还是把密码保存在了 git repo 里, 是尽量要避免的.

要是用 GitHub Actions 的 CI/CD, secret 也不会在多个途径使用的话, GitHub 里的 Secret 管理也是可靠的.

但一般生产环境, 一个第三方的 secret 管理工具[SaaS 或 self-host]还是需要的.
HashiCorp 的 Vault 就是很好的选择, 能 SaaS, 也能公司自己 self-host, 国内国外都用得很广泛, 第三方支持也很广泛. 各种 CI/CD 工具基本都支持动态从其中获取 secret.

我估计这些镜像安装中不会自己检测自己的完整性, 这个超出了一个系统安装镜像的考虑范围吧.

但用户应该可以写一个 PowerShell 脚本之类的, 定期运行检查指定位置存储的 iso 文件并和存储的检验码进行比对, 用来简单实现 iso 篡改检测, 这个应该可行吧.

关于: 是应用 CI 自身的模块来编写更原生化的 pipeline, 还是使 CI 基本仅负责调用,组织和粘合 shell/python script 的执行.
我个人倾向于后者, 确实是会更方便在多种 CI 工具之间迁移.

不论如何, 把 sensitive 的配置加密到代码里都不是首选方案吧.

把这些 sensitive 配置 抽取为输入变量 , 并转换为 自动从环境变量取值, pipeline 中由 jenkins/github actions 等从自身的 secret 或第三方 secret manager 获取 secret 并注入到 运行时环境变量 来实现相应配置的赋值, 这样才是一般比较广泛使用的平衡了安全性与复杂度的方案吧.

协议呢 ? 端口也分 TCP/UDP 的, 检查下.
确认以下情况:
1. 确认设置的安全组是否是被应用在此 instance 上的安全组.
2. 确认下协议是否正确.
3. 安全组之外, 还有一层网络控制机制 Network Access Control Lists , 确认下是否开启了 NACL.
4. 外部网络之外, 再确认下 EC2 instance 系统内部, 此端口是否被其它应用占用, 导致无法访问.

有理想, 有追求 !

目前的税务制度 "发展中" 的离谱 ... 本应该是一个年度整体统计, 多退少补的过程, 但由于社会中"黑灰资金"比例太大, 与其多退少补, 不如有一笔扣一笔来的"简单粗暴又直接".

但是当然, 这套税务制度也不是多么的"税务", 本身也不是建立在 "义务"与"权力"之上的, 所以只会让人觉着自己失去了一部分资产, 却又没换来什么"权力", 所以有种相当的"损失"感.

当然，不讨论生活状态， 还有一种可能， 很简单， 就是你“完美主义”者，玩游戏中前期什么都要力图完美，所以玩得很慢，所以时间拖得很久， 所以 到游戏后期就把自己都搞得逐渐失去兴趣了 ...

BG3 110h 刚到第三章 ??

如果你人在体制内，生活也没什么困难，整体处于很清闲舒适的状态， 那你玩 500 小时也能继续玩下去，而且饶有兴致。

如果你不处在类似于上面这种状态，大部分人大概都不处在以上这种状态， 那你玩 50 小时都会觉着玩不下去了。

所以， 没那生活状态就别花太长时间玩游戏，或许一个游戏 20 至 30 小时的游戏时间更合适你