以下是 Azure 常用服务的清单，按照与 AWS 相同的分类和架构逻辑整理，便于从 AWS 迁移或对比学习：

架构图​

1. 核心请求流​

在系统设计中，了解硬件资源限制、数据库性能指标和常见数据规模是至关重要的。以下是整理的关键参数和参考范围，涵盖数据规模、硬件配置、数据库性能等方面：

一、数据规模参考​

1. 中英文字符的存储大小​

说明：

1. 英文字符 在 ASCII 和 UTF-8 编码下均占 1 字节。
2. 中文字符 在 UTF-8 编码下通常占 3 字节，而在 GBK/GB2312 编码下占 2 字节。
3. 示例计算 展示了 VARCHAR(100) 字段在存储不同字符时的近似大小（包含长度标识）。

2. 数据库常见数据类型大小​

3. 文件/数据大小​

运维工程师需要掌握的知识体系非常广泛且不断演进，核心在于保障系统/服务的稳定性、安全性、效率和成本可控。以下是一个结构化的框架和表格，帮助你系统性地理解和拆分运维所需掌握的核心内容：

核心框架：四大能力域 + 两大支撑域

1. 基础设施管理： 支撑应用运行的物理/虚拟基础。
2. 系统与平台管理： 操作系统、数据库、中间件等核心软件平台的管理。
3. 应用部署与运维： 应用的发布、运行监控、问题排查、性能调优。
4. 自动化与流程： 提升效率、减少人为错误、保证一致性的关键。
5. 网络与安全： 贯穿所有层次的连接和安全保障。
6. 监控与可观测性： 系统的“眼睛”和“听诊器”，是稳定性的基石。

详细拆分表格​

一、 核心目标分解​

• 稳定性 (Stability):
  • 系统抵御故障、快速恢复的能力。
  • 目标：降低故障发生率 (MTBF - Mean Time Between Failures)。
• 可用性 (Availability):
  • 系统在需要时可被正常使用的程度。
  • 目标：最大化正常运行时间 (Uptime)，通常用 SLA (如 99.9%, 99.99%) 衡量。
• 一致性 (Consistency):
  • 确保环境、配置、部署流程、行为在开发、测试、生产等所有阶段高度一致。
  • 目标：消除“在我机器上是好的”问题，减少环境差异导致的故障。

二、 DevOps 达成目标的支柱策略​

1. 基础设施即代码 (IaC)​

找到理想的技术工作确实不仅需要扎实的硬技能，更需要掌握一套有效的面试策略和认知方法。

心法指南​

下面是整理的全面指南，希望能帮你更有信心地迎接挑战：

🧠 一、 核心认知：转变思维，理解面试本质​

1. 面试不是考试，而是价值交换的对话：

   • 核心： 你不是在被"考"，而是在与公司探讨"我如何能解决你们的问题/达成你们的目标"。
   • 认知： 公司有痛点（技术债、新项目、性能瓶颈、团队协作问题等），你拥有技能和经验。面试是展示你如何匹配并解决这些痛点的过程。时刻思考："我能为他们带来什么独特价值？"

最近在看《段永平投资问答实录》这本书，正文第一页就说，投资实际上就是投公司，投公司的判断标准就是看懂商业模式和企业未来现金流的折旧(企业终值是企业未来现金流的一种)。

我当时就在想，这是什么？于是就有了这篇研究整理后的博文。

企业未来现金流折现 DCF​

定义​

现金为王

企业未来现金流折现（Discounted Cash Flow, DCF）是一种评估企业或投资项目内在价值的核心方法。它的核心思想是：

一家公司的价值，等于它在未来所能产生的所有自由现金流的当前价值总和。

简单来说，就是“未来的钱，不如现在的钱值钱”。因此，我们需要把公司未来赚到的钱（现金流），按照一定的“折扣率”（折现率）折算回现在的价值，然后加总起来，这个总和就被认为是公司的内在价值或公允价值。

核心要素和计算逻辑​

最近想把个人播客做一个升级，发现从 Docusaurus_v2 升级到 Docusaurus_v3 有很多各种各样的配置问题。

于是我决定重新初始化 Docusaurus_v3 的项目，并在此文记录整个过程。

最近做了几个运维工程师的面试，发现其实很多运维工程师并未使用像 Datadog 这类全栈监控 Saas 方案，大部分都是 Prometheus 的监控方案，所以我就有一个问题:

如果我们不使用 Datadog 服务，我们是否能够通过开源软件构建出一个全栈监控解决方案？

引用 全局架构设计