100 Days of DevOps, Day 4: Permissions That Actually Matter and Why S3 Versioning Shouldn’t Be Optional

DevOps 百日挑战，第 4 天：至关重要的权限管理与为何 S3 版本控制不应是可选项

Not every mistake breaks a system immediately. Some mistakes just sit there quietly until the wrong person gets access, or someone deletes the wrong file, or a deployment goes sideways. Today’s tasks were about putting guardrails in place before those moments happen. 并非每一个错误都会立即导致系统崩溃。有些错误会静静地潜伏在那里，直到错误的人获得了访问权限，或者有人误删了文件，又或者部署过程出了岔子。今天的任务重点在于在这些时刻发生之前，先建立起安全护栏。

Task 1 (Linux): Set Script Execution Permissions

任务 1 (Linux)：设置脚本执行权限

A script isn’t useful if it can’t be executed. But making everything executable for everyone isn’t the answer either. Linux permissions exist so you can decide exactly who gets to do what. 如果脚本无法执行，它就毫无用处。但让所有人都能执行所有文件也不是解决之道。Linux 权限的存在，就是为了让你能够精确地决定谁可以做什么。

# SSH into the target server via the jump server
ssh user@hostname
# Navigate to the script location
cd /path/to/script
# Grant execute permission
sudo chmod 755 /path/to/script.sh
# Verify permissions
ls -l /path/to/script.sh

Key points: 关键点：

• chmod 755 means the owner gets read, write, and execute permissions, while the group and everyone else can only read and execute. chmod 755 意味着所有者拥有读、写和执行权限，而组用户和其他人只能读取和执行。
• Running ls -l should show something like -rwxr-xr-x. The leading - simply tells you it’s a regular file. ls -la is useful when you also want to see hidden files in the directory. 运行 ls -l 应该会显示类似 -rwxr-xr-x 的内容。开头的 - 只是告诉你这是一个普通文件。当你还想查看目录中的隐藏文件时，ls -la 非常有用。
• One thing I’ve started appreciating is that Linux permissions aren’t just about making something work—they’re about limiting what doesn’t need to happen. If a script only needs one person to modify it, there’s no reason to let everyone else have write access. Least privilege sounds like a security buzzword until someone accidentally edits a production script. 我开始意识到，Linux 权限不仅仅是为了让程序正常运行，更是为了限制那些不必要的操作。如果一个脚本只需要一个人修改，就没有理由让其他人拥有写权限。“最小权限原则”听起来像是一个安全术语，直到有人不小心修改了生产环境的脚本，你才会真正理解它的重要性。

---

Task 2 (AWS): Enable Versioning on an S3 Bucket

任务 2 (AWS)：启用 S3 存储桶的版本控制

Deleting the wrong file is inevitable. Whether it’s human error, a faulty deployment, or an application bug, objects eventually disappear or get overwritten. S3 Versioning exists so those mistakes don’t automatically become disasters. 误删文件是不可避免的。无论是人为失误、错误的部署还是应用程序的 Bug，对象最终总会消失或被覆盖。S3 版本控制的存在，就是为了确保这些错误不会自动演变成灾难。

# Check current versioning status
aws s3api get-bucket-versioning --bucket my-bucket-name
# Enable versioning
aws s3api put-bucket-versioning \
    --bucket my-bucket-name \
    --versioning-configuration Status=Enabled
# Verify
aws s3api get-bucket-versioning --bucket my-bucket-name

Key points: 关键点：

• Once versioning is enabled, it can’t be completely turned off—it can only be suspended. 一旦启用了版本控制，它就无法被彻底关闭，只能被挂起（Suspended）。
• Every version of every object is stored separately, so storage costs increase over time. 对象的每个版本都会被单独存储，因此存储成本会随时间增加。
• Versioning is required for S3 Replication and is commonly expected in backup and compliance environments. S3 复制功能需要版本控制，且在备份和合规性环境中，这通常是必备要求。
• The interesting thing is that versioning doesn’t stop people from making mistakes. It just gives you a way back. Recovery is often more valuable than prevention because nobody gets everything right all the time. 有趣的是，版本控制并不能阻止人们犯错，它只是为你提供了一条退路。恢复往往比预防更有价值，因为没有人能永远不出错。

---

What Day 4 Is Really About

第 4 天的真正意义

Today’s tasks looked unrelated. One was about Linux file permissions. The other was about object storage. But they’re solving the same problem: reducing the impact of human error. Permissions stop the wrong people from changing things. Versioning lets you recover when the right people change the wrong thing. Neither feature makes a system more exciting. They just make it far more forgiving. 今天的任务看起来毫无关联。一个是关于 Linux 文件权限，另一个是关于对象存储。但它们解决的是同一个问题：减少人为失误的影响。权限管理阻止了错误的人进行修改，而版本控制则让你在正确的人做错事时能够恢复。这两个功能都不会让系统变得更“酷”，但它们确实让系统变得更加宽容。

So here’s the question. If someone accidentally deleted an important file or modified a production script today, how quickly could you recover? The best time to prepare for mistakes is before anyone makes one. 所以问题来了：如果今天有人不小心删除了重要文件或修改了生产脚本，你能多快恢复？为错误做准备的最佳时机，就是在错误发生之前。