ka1h 修订了这个 Gist . 跳至此修订
1 file changed, 47 insertions
work_right_fast.md(file created)
| @@ -0,0 +1,47 @@ | |||
| 1 | + | The original phrase, "Make it work, make it right, make it fast," is a classic software development mantra, often attributed to Kent Beck (though variations exist). It describes a pragmatic approach to development. | |
| 2 | + | ||
| 3 | + | Let's break down how DevOps and SRE might interpret or spin it: | |
| 4 | + | ||
| 5 | + | **The Original: "Make it work, make it right, make it fast"** | |
| 6 | + | ||
| 7 | + | * **Make it work:** Get the basic functionality operational. Prove the concept. | |
| 8 | + | * **Make it right:** Refactor, ensure correctness, improve design, add tests, make it maintainable. | |
| 9 | + | * **Make it fast:** Optimize for performance and efficiency. | |
| 10 | + | ||
| 11 | + | This phrase, as is, aligns quite well with general agile software development, which **DevOps heavily leverages and builds upon.** DevOps aims to do all three of these things *continuously and rapidly* through its practices (CI/CD, automation, collaboration). The "fast" in a DevOps context also strongly implies fast delivery cycles. | |
| 12 | + | ||
| 13 | + | **DevOps Focus/Spin:** | |
| 14 | + | ||
| 15 | + | DevOps wouldn't necessarily *change* the core phrase as much as *emphasize the process and lifecycle around it*. A DevOps interpretation might implicitly add: | |
| 16 | + | ||
| 17 | + | * "...and **automate its delivery**." | |
| 18 | + | * "...and **get feedback quickly**." | |
| 19 | + | * "...and **ensure shared responsibility** for all three." | |
| 20 | + | ||
| 21 | + | So, for DevOps, it's about enabling teams to go through "work, right, fast" cycles very quickly and reliably for every feature or change. The "fast" is as much about the *delivery pipeline* and iteration speed as it is about application performance. | |
| 22 | + | ||
| 23 | + | **SRE Focus/Spin:** | |
| 24 | + | ||
| 25 | + | SRE (Site Reliability Engineering) has a very strong focus on reliability, scalability, and operational excellence. An SRE spin would likely re-prioritize or re-interpret the terms: | |
| 26 | + | ||
| 27 | + | A strong SRE spin could be: | |
| 28 | + | ||
| 29 | + | 1. **"Make it reliable."** | |
| 30 | + | * This inherently covers "make it work" (it has to work to be reliable) and a significant part of "make it right" (correctness, fault tolerance, robustness are key to reliability). It's the absolute foundation for SRE. | |
| 31 | + | 2. **"Make it observable (and measurable)."** | |
| 32 | + | * If you can't see what it's doing or measure its performance against SLOs, you can't effectively manage its reliability or make it "fast" in a meaningful way. This is a prerequisite for both "right" and "fast" from an operational standpoint. | |
| 33 | + | 3. **"Make it scalable/efficient (and fast to recover)."** | |
| 34 | + | * "Fast" for SRE often means performant under load (scalability), efficient in resource usage (cost/capacity), and critically, *fast to detect and recover* from incidents (MTTD/MTTR). | |
| 35 | + | ||
| 36 | + | **So, an SRE-focused spin might be:** | |
| 37 | + | ||
| 38 | + | * **"Make it reliable, make it observable, make it scalable/efficient."** | |
| 39 | + | or | |
| 40 | + | * **"Make it work (reliably), make it right (by SLOs), make it fast (to recover/scale)."** | |
| 41 | + | ||
| 42 | + | **Conclusion:** | |
| 43 | + | ||
| 44 | + | * The original "Make it work, make it right, make it fast" is a general software development principle that **DevOps adopts and aims to accelerate through its practices.** | |
| 45 | + | * An **SRE-focused spin** would more explicitly prioritize **reliability, observability, and operational characteristics** like scalability, efficiency, and fast recovery, often framing "right" in terms of meeting Service Level Objectives (SLOs). | |
| 46 | + | ||
| 47 | + | Therefore, a spin like **"Make it reliable, make it observable, make it scalable"** is decidedly more **SRE-focused.** | |
更新
更早