devops

by Michael Shilman

通过迈克尔·希尔曼(Michael Shilman)

最低可行DevOps (Minimum Viable DevOps)

快速而肮脏的指南，用于扩展您的发布并拥抱互联网的死亡 (A quick and dirty guide to scaling your launch and embracing the Internet hug of death)

Startup Genome says premature scaling is the number one cause of startup death. You shouldn’t spend time optimizing a product when you don’t even know if users want it.

启动Genome说过早扩展是启动死亡的第一大原因。当您甚至不知道用户是否想要产品时，就不应该花时间优化产品。

Yet every time you launch a web app, you run the risk of actually succeeding, and your server should be ready to handle the load.

但是，每次启动Web应用程序时，都会冒实际成功的风险，并且服务器应准备好处理负载。

In this article I’ll share a simple, free recipe to get your app launch-ready. An hour spent following these steps will save you countless hours of sleep over the course of your product’s lifetime.

在本文中，我将分享一个简单的免费食谱，以使您的应用程序可以启动。按照这些步骤花费一个小时，可以为您节省产品生命周期中无数小时的睡眠。

In a nutshell:

简而言之：

Benchmark using a load-testing tool like Loader.io.使用诸如Loader.io之类的负载测试工具进行基准测试。
Use a caching proxy like NGINX to mitigate server load.使用NGINX之类的缓存代理来减轻服务器负载。
Use a CDN like Cloudflare for fast loading and global distribution.使用Cloudflare这样的CDN可以快速加载和全局分发。

第一世界问题 (First-World Problems)

Let’s get this out of the way. Having too much traffic to your website is a first-world problem, and writing about it is the ultimate humblebrag. Guilty on all fronts. Sue me.

让我们解决这个问题。网站访问量过多是一个首要问题，而撰写有关内容则是最终的谦虚。在各个方面都感到内。告我。

But it’s still a problem. The startup world is filled with tales of services hitting the front page of Reddit, getting “unexpectedly” hunted on Product Hunt, and so forth. It’s a cliche at this point.

但这仍然是一个问题。初创企业世界中充斥着各种服务故事，这些事件涉及Reddit的首页，在“产品搜索”中被“意外地”发现，等等。这是陈词滥调。

This article is the opposite of that. In the past year I’ve launched three services to millions of users and slept like a baby while my server was getting hammered by clicks, with zero downtime.

本文与之相反。在过去的一年中，我为数百万的用户推出了三项服务，并且在我的服务器受到点击的冲击，零停机的情况下像婴儿一样睡觉。

Hello Money is Reddit’s tool of choice for portfolio visualization and peer feedback. Spikes: It ranked #1 on Product Hunt the day it launched and named by PH as one of the 7 best personal finance apps, has reached the top of /r/personalfinance multiple times (nearly 7M readers), and has been featured on Hacker News.

Hello Money是Reddit进行投资组合可视化和同行反馈的首选工具。 尖峰：它在产品发布之日就被Product Hunt排名第一，并被PH评为7项最佳个人理财应用程序之一，已多次达到/ r / personalfinance的顶部(近700万读者)，并在Hacker上被推荐新闻。

Goodbye Gun Stocks shows socially-conscious investors whether their mutual fund and ETFs are invested in gun companies and helps them find similar gun-free funds with lower fees and better historical returns. Spikes: written up in New York Daily News, Fortune, Time, Fast Company, Vice (Twice!), GOOD, it’s the #1 politics app on Product Hunt excluding Trump jokes (which are hard to compete with!). It’s also gotten a lot of love on both Twitter and Facebook.

再见枪支股票向有社会意识的投资者展示了他们的共同基金和ETF是否投资于枪支公司，并帮助他们找到了类似的无枪支基金，具有更低的费用和更好的历史回报。 尖峰：写在《纽约每日新闻》，《财富》，《时代》，《快公司》，《恶棍》 ( 两次！ )，《好》上，它是Product Hunt上排名第一的政治应用，不包括特朗普的笑话(很难与之抗衡！)。它在Twitter和Facebook上也引起了人们的极大关注。

Sidebar is Sacha Greif’s daily design newsletter. Sacha is a design powerhouse with over 20k twitter followers, numerous massive mailing lists, and an abundance of Hacker News karma. Whenever he launches anything it gets flooded with attention, so before he launched a redesign of Sidebar, I used this game plan to help make sure it could handle the load.

补充工具栏是Sacha Greif的每日设计时事通讯。萨莎(Sacha)是一家设计巨头，拥有超过2万个Twitter粉丝，众多庞大的邮件列表以及大量的Hacker News业力。每当他发布任何东西时，都会引起人们的注意，因此，在他重新设计Sidebar之前，我使用了这个游戏计划来帮助确保它可以处理负载。

第三世界解决方案 (Third-World Solution)

For anybody who has built a truly Internet-scale service, like Google, Facebook, Amazon, I apologize in advance. Likewise, if you list DevOps as one of your skills you may be sickened by what you read here.

对于任何构建了真正的Internet规模服务的人，例如Google，Facebook，Amazon，我都表示歉意。同样，如果将DevOps列为您的技能之一，则可能会对此处的内容感到不适。

What I’m describing is a quick bandaid solution for startup folks like me who are ecstatic when their site receives 100,000 visitors in a shot. For a long-term scaling solution, look somewhere else.

我正在描述的是一种快速创可贴解决方案，适用于像我这样的创业者，他们的网站一枪吸引了100,000名访问者时欣喜若狂。对于长期扩展解决方案，请寻找其他地方。

I’ll present the solution in order. Plan to spend an afternoon on it the first time you implement this flow. Once you’re comfortable with it, you should be able to get a site ready in an hour or so.

我将按顺序介绍解决方案。计划在第一次实施此流程时在上面花费一个下午。适应之后，您应该可以在一个小时左右的时间内准备好网站。

Here are the steps again:

再次执行以下步骤：

Benchmark using a load-testing tool like Loader.io.使用诸如Loader.io之类的负载测试工具进行基准测试。
Use a caching proxy like NGINX to mitigate server load.使用NGINX之类的缓存代理来减轻服务器负载。
Use a CDN like Cloudflare for fast loading and global distribution.使用Cloudflare之类的CDN可以快速加载和全局分发。

1.全力以赴的母亲 (1. The Mother of all Loads)

The first step in getting ready is to measure your existing service under load, simulating thousands of user visits over a 1-minute interval.

准备工作的第一步是评估负载下的现有服务，在1分钟的间隔内模拟成千上万的用户访问。

There are a million different open source tools for load testing, but we want to get everything done in an hour, so we’ll use Loader.io, a free SaaS that’s trivial to set up and use.

有上百万种用于负载测试的开源工具，但我们希望在一小时内完成所有工作，因此我们将使用Loader.io ，这是一个免费的SaaS，易于安装和使用。

There are only a few parameters you need to configure and then you’re set:

仅需配置几个参数，然后进行设置：

If you haven’t done any optimizations yet, the first run will probably break your service, and that’s OK. Here’s me breaking Goodbye Gun Stocks during my launch prep:

如果您尚未进行任何优化，则第一次运行可能会中断您的服务，没关系。这是我在准备发射时打破再见枪支的原因：

On the X axis is time, and the Y axis shows both active clients and average response time. Over time, both of these values increase steadily. Response time starts at 0 and grows to over 10 seconds during the course of the run. This is because the service is unoptimized and can’t handle the requests in time. Requests back up and everything grinds to a halt.

X轴上是时间，Y轴上同时显示活动的客户端和平均响应时间。随着时间的流逝，这两个值都稳定增加。响应时间从0开始，在运行过程中增长到10秒钟以上。这是因为服务未优化，无法及时处理请求。请求备份，一切都停止了。

In contrast, here’s what a successful run looks like. The response time is down to an average of 9ms and stays that way through most of the run, occasionally spiking up to around 17ms.

相反，这是成功运行的样子。响应时间平均下降到9毫秒，并且在整个运行过程中一直保持这种状态，偶尔会增加到17毫秒左右。

Note that since this is a quick-and-dirty approach to load testing, it has its limitations:

请注意，由于这是一种负载测试的快速方法，因此它有其局限性：

Limited load. Loader.io’s free plan is limited to a maximum of 10,000 requests per minute, but that’s more than most services will get, even if they top out ProductHunt, Hacker News, and Reddit. If you really care, you can just upgrade to a paid version.

有限的负载。 Loader.io的免费计划限制为每分钟最多10,000个请求，但这比大多数服务将获得的服务还要多，即使它们超越了ProductHunt，Hacker News和Reddit。如果您真的很在意，则可以升级到付费版本。
HTTP/S only. Loader.io only supports HTTP/S requests for now. Some modern web apps, such as Meteor (which was used to build all three services above) also use websockets for communication. If you really care, you can use other tools to load test, but you probably won’t be done in an hour. For example Meteor has MeteorDown for load testing. Kadira, by the same authors, is the best tool hands-down for understanding Meteor performance issues.

仅HTTP / S。 Loader.io目前仅支持HTTP / S请求。一些现代的Web应用程序，例如Meteor (用于构建上述所有三个服务)也使用websocket进行通信。如果您真的很在意，可以使用其他工具进行负载测试，但是您可能不会在一小时内完成。例如，Meteor具有MeteorDown用于负载测试。同一作者的Kadira是了解流星性能问题的最佳工具。

2. NGINX：互联网的创可贴 (2. NGINX: The Band-Aid of the Internet)

If your service survived the load test, you may as well launch now. If not, you might be second-guessing yourself, and it’s probably worth seeing whether there’s a quick fix.

如果您的服务在负载测试中幸免于难，那么您最好立即启动。如果不是这样，您可能会second不休，并且值得一看是否有快速解决方案。

There are so many possible explanations for what went wrong, and even for a small app you could spend a lifetime tuning server configurations, database queries, and badly-written loops.

关于发生问题的原因有很多可能的解释，即使对于小型应用程序，您也可以花费一生的时间来调整服务器配置，数据库查询和写得不好的循环。

But screw all that. NGINX is a free, open-source high-performance web server and jack-of-all-trades proxy. You can use it to smooth over most performance issues with a small time investment. After you learn it, it will be a trusted tool you can use for kludging over everything you build in the future.

但是拧紧所有。 NGINX是免费的开源高性能Web服务器和万事通代理。您可以用它花费少量时间来解决大多数性能问题。学习之后，它将成为可信任的工具，可用于将来整合您构建的所有内容。

The key thing about NGINX is that it’s blazingly fast and with a little work you can configure it to do almost anything. For all of my services, I run an NGINX server in front of the actual service, as a caching load-balancing reverse proxy:

NGINX的关键在于它的速度非常快，只需做一些工作，您就可以配置它执行几乎所有操作。对于我的所有服务，我在实际服务之前运行NGINX服务器，作为缓存负载平衡反向代理：

设定 (Setting it up)

Setting up NGINX is a quick and well-documented process. The confusing thing is that it does so many different things it can be difficult to configure. So I’ll cut to the chase and share the configuration we’re using for Sidebar, and explain it so you can use it as a starting point for optimizing your own service:

设置NGINX是一个快速且有据可查的过程。令人困惑的是，它完成了许多不同的事情，可能难以配置。因此，我将继续进行介绍，并分享我们用于补充工具栏的配置，并对其进行解释，以便您可以将其用作优化自己的服务的起点：

There are three key things going on here:

这里有三项关键的事情：

Reverse Proxy. All the configuration lines below the PROXY STARTS HERE line configures NGINX to be a reverse proxy, meaning that it forwards requests on to your web app, fetches the response, and returns the response to the requestor.

反向代理。 PROXY STARTS HERE行下面的所有配置行都将NGINX配置为反向代理，这意味着它将请求转发到Web应用程序，获取响应，并将响应返回给请求者。
Load Balancer. The upstream declaration at the top configures NGINX to also be a load-balancer, so it can farm requests out to multiple back-end servers instead of just one.

负载均衡器。 顶部的上游声明将NGINX配置为也是负载平衡器，因此它可以将请求发送到多个后端服务器，而不仅仅是一个。
Cache. Everything after the CACHING line sets NGINX up to be a cache, meaning that NGINX can store some of the responses and return the results without ever hitting the back-end app server.

快取。 CACHING行之后的所有内容都将NGINX设置为缓存，这意味着NGINX可以存储一些响应并返回结果，而无需访问后端应用服务器。

NGINX as a reverse proxy is not important in and of itself, but it enables load balancing and caching, which are both awesome for scalability. So let’s drill into those a bit.

NGINX作为反向代理本身并不重要，但是它可以实现负载平衡和缓存，这对于可伸缩性都很棒。因此，让我们深入研究一下。

负载均衡器 (Load Balancer)

Load balancing means that you can set up multiple app servers to run your app. This has a few benefits:

负载平衡意味着您可以设置多个应用服务器来运行您的应用。这有一些好处：

Horizontal Scalability. If your app is CPU- or memory-bound, and your traffic maxes out your server, you can easily add another back-end server.

水平可伸缩性。 如果您的应用是受CPU或内存限制的，并且您的流量使服务器用尽了，您可以轻松添加另一台后端服务器。
Dynamic Redeployment. If you need to modify your server code, you can spin up a new machine running the new code, test it out, and then add it into the load-balancer

动态重新部署。 如果您需要修改服务器代码，则可以启动一台运行新代码的新计算机，对其进行测试，然后将其添加到负载均衡器中
Fault Tolerance. If one of your servers crashes or gets overloaded, NGINX can be configured to automatically remove it from the list. The configuration above does not do this, but it’s possible to add.

容错能力。 如果您的一台服务器崩溃或过载，可以将NGINX配置为自动从列表中删除它。上面的配置不执行此操作，但是可以添加。

The only down-side to running a load balancer is a minor increase complexity (totally worth it), and potentially increased server costs. Note that you can also proxy to a server running on a different port on the same machine to save cost, and NGINX is so efficient that this is OK for all but giant loads.

运行负载平衡器的唯一缺点是增加的复杂性很小(完全值得)，并且可能增加服务器成本。请注意，您还可以代理到同一台计算机上不同端口上运行的服务器，以节省成本，而NGINX的效率非常高，对于巨大的负载而言，这都是可以的。

快取 (Caching)

Caching means that HTTP responses are stored disk for some period, and when a client makes the same request during that cache period, NGINX will return the cached response rather than hitting the app server.

缓存意味着HTTP响应在磁盘上存储了一段时间，当客户端在该缓存期内发出相同的请求时，NGINX将返回缓存的响应，而不是访问应用服务器。

This has a couple key benefits:

这有几个主要好处：

Decreased server load. NGINX is incredibly efficient and can handle thousands of requests on a normal server. I’ve never run into any problems with it, even running high-traffic sites. The real problem is with app servers or databases, and every cached response from NGINX is one less request that the app server needs to handle.

减少服务器负载。 NGINX非常高效，可以在普通服务器上处理数千个请求。我从来没有遇到任何问题，即使是在人流量大的网站上也是如此。真正的问题出在应用服务器或数据库上，NGINX的每个缓存响应都比应用服务器需要处理的请求少一个。
Response speed. The cached responses are super fast. If your data is not rapidly changing or user-specific, then the user should see the result in milliseconds if she is on a reasonably fast connection.

响应速度。 缓存的响应非常快。如果您的数据不是快速变化或不是特定于用户的，则如果用户处于相当快速的连接状态，则用户应该以毫秒为单位查看结果。

Unlike load balancing, caching can have some downsides, and you should be careful about how you cache.

与负载平衡不同，缓存可能会有一些缺点，因此在缓存时应格外小心。

Stale data. The most obvious problem is stale data. If your data has lots of highly dynamic data like a realtime stock site, or lots of user-specific data, then caching is a challenge. However, most pages and apps have a mostly static homepage which captures most of the traffic, and then a more dynamic sections which much fewer users click through to. If your service has this pattern, you can cache the former, and leave the latter uncached.

过时的数据。 最明显的问题是陈旧的数据。如果您的数据包含大量高度动态的数据(例如实时库存站点)或大量特定于用户的数据，则缓存是一个挑战。但是，大多数页面和应用程序都有一个主要是静态的主页，可以捕获大多数流量，然后是一个动态的部分，用户点击率会降低。如果您的服务具有此模式，则可以缓存前者，而不缓存后者。
Decreased security. If your responses have user-sensitive data in them, you cannot cache them. Be careful about caching and security! In the configuration above that we created a $skip_cache variable to avoid caching for signed-in users. We test for the cookie meteor_login_token but this should be easy to customize for your setup.

安全性降低。 如果您的响应中包含用户敏感数据，则无法缓存它们。注意缓存和安全性！在上面的配置中，我们创建了$ skip_cache变量以避免对登录用户进行缓存。我们测试了cookie meteor_login_token，但这应该很容易针对您的设置进行自定义。
Complexity / Debug-ability. As soon as you start caching you introduce a major new source of complexity into the system. When something goes wrong is it because there’s a bug in the service, or a bug in the cached response, or?

复杂性/调试能力。 一旦开始缓存，就将复杂性的主要新来源引入系统。当出现问题时，是因为服务中存在错误，还是缓存的响应中存在错误，或者？

In spite of the problems with caching, with a little practice it can be a great quick fix for almost any performance issue. There are plenty of other places you can cache too (database requests, etc.), but NGINX is easy.

尽管存在缓存问题，但只要稍加实践，它几乎可以解决几乎所有性能问题。您还可以缓存许多其他地方(数据库请求等)，但是NGINX很容易。

重新运行您的负载测试 (Re-run Your Load Test)

As you optimize your service, re-run your load test. Here’s Goodbye Gun Stocks after receiving some NGINX love:

在优化服务时，请重新运行负载测试。收到一些NGINX的爱之后，这里是再见枪支：

After your service is handling the load, be sure to do manual testing to make sure you haven’t broken anything. Be sure to test basic functions like user signin / signout, since those are things that are easy to mess up when you cache. If everything looks good, you should be good to go.

服务处理完负载后，请确保进行手动测试以确保您没有损坏任何东西。确保测试诸如用户登录/注销之类的基本功能，因为这些功能在缓存时很容易弄乱。如果一切看起来都不错，那您应该就很好了。

Setting up NGINX like this can cover up even the most inefficient server code. It can take some fiddling, but for most apps it will do the trick for getting you launch ready in a snap.

这样设置NGINX甚至可以掩盖效率最低的服务器代码。这可能需要花些时间，但对于大多数应用程序而言，它可以使您Swift启动启动。

3.走向全球 (3. Going Global)

OK, you’ve gotten through the hard part and you’ve got a service that can withstand most traffic spike. But the Internet is a global village, and if you post your service to any major traffic source, you’ll be getting traffic from the other side of the planet. Let’s make sure those users have a decent experience too.

好的，您已经完成了最困难的部分，并且您已经获得了可以承受大多数流量高峰的服务。但是Internet是一个全球性的村庄，如果您将服务发布到任何主要的流量来源，您都会从地球的另一端获得流量。让我们确保这些用户也有不错的体验。

Fortunately, there are Content Delivery Networks for this. I recommend Cloudflare. The basic options are free and should be more than enough for your MVP.

幸运的是，这里有内容传送网络。我推荐Cloudflare 。基本选项是免费的，对于您的MVP来说应该绰绰有余。

In addition to making all your static assets load faster, setting up Cloudflare has a few other benefits:

除了可以更快地加载所有静态资产外，设置Cloudflare还具有其他一些好处：

Security. Cloudflare gives you one-click HTTPS. Setting up HTTPS on your server can be a pain, even with awesome services like LetsEncrypt that make it relatively cheap and easy. Cloudflare provides a minimal HTTPS with a click of a button, even if your server is only running HTTP. This is good enough for many minimum viable products, though if you’re dealing with sensitive information such as finance or health security, you should definitely encrypt the entire flow.

安全。 Cloudflare为您提供一键式HTTPS。在服务器上设置HTTPS可能会很痛苦，即使使用诸如LetsEncrypt之类的出色服务也可以使其相对便宜和容易。即使您的服务器仅运行HTTP，Cloudflare只需单击一个按钮即可提供最小的HTTPS。这对于许多最低限度可行的产品已经足够了，尽管如果您要处理诸如财务或健康安全之类的敏感信息，则必须对整个流程进行加密。
DDoS protection. When I was launching Goodbye Gun Stocks, I worried about potential denial of service attacks since gun violence prevention is a hot-button issue in the US. It ended up not being a problem, but if it had been Cloudflare has some built-in service to help handle that. I haven’t used it, but it’s great to know somebody has your back.

DDoS保护。 当我推出“再见枪械库存”时，我担心潜在的拒绝服务攻击，因为在美国，枪支暴力预防是一个紧迫的问题。最终这不是问题，但如果是Cloudflare，它会提供一些内置服务来解决该问题。我没用过，但是很高兴知道有人支持你。

好的，现在发货！ (Ok, Now Ship it!)

Using this launch kit you can quickly take your new service from minimum viable product to a load-tested, launch-ready, and globally accessible service. This is all possible using free tools and a minor time investment.

使用此启动工具包，您可以快速将新服务从最低可行的产品转变为经过负载测试，可启动且可全球访问的服务。使用免费工具和少量时间投入，一切皆有可能。

If your service goes totally viral like The Dress, whose Tumblr page received 14,000 views a second at its peak, then these techniques probably won’t cut it, and your servers may end up in a smoking heap. But hey, there are worse problems to have!

如果您的服务像The Dress一样完全病毒化，其Tumblr页面在高峰时每秒收到14,000次观看，则这些技术可能不会减少它，您的服务器可能最终陷入一片烟雾。但是，嘿，还有更严重的问题！

Comment below with questions or suggestions. And follow me here or on Twitter for more great articles coming down the pipe.

在下面用问题或建议发表评论。并在这里或在Twitter上关注我，以获取更多精彩文章。

Best of luck and happy launching!

祝您好运，祝发射愉快！

And finally, if this was useful, please tap the ? button below. Thanks!

最后，如果这很有用，请点击？ 下方的按钮。 谢谢！

Many thanks to Keywon for making Hello Money and Goodbye Gun Stocks launches a success and introducing me to this “problem”; Sacha Greif and Josh Owens for Sidebar ops collaboration; WooGenius for figuring out load testing with me.

非常感谢Keywon制作的《 Hello Money》和《 Goodbye Gun Stocks》获得成功，并向我介绍了这个“问题”。 Sacha Greif和Josh Owens合作进行Sidebar操作； WooGenius与我一起进行了负载测试。

Header image: Jeff Eaton

标头图片： Jeff Eaton

翻译自: https://www.freecodecamp.org/news/minimum-viable-devops-919972dfd9e0/