From 53fec5d1a70091d61ce5e3209f7637a04e2fb286 Mon Sep 17 00:00:00 2001
From: geek <34594958+geekmar@users.noreply.github.com>
Date: Tue, 7 Aug 2018 12:49:20 +0800
Subject: [PATCH] =?UTF-8?q?Create=2020180803=20What=20data=20is=20too=20ri?=
 =?UTF-8?q?sky=20for=20the=20cloud=E9=80=89=E9=A2=98=20What=20data=20is=20?=
 =?UTF-8?q?too=20risky=20for=20the=20cloud.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...‰é¢˜ What data is too risky for the cloud.md | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 translated/talk/20180803 What data is too risky for the cloud选题 What data is too risky for the cloud.md

diff --git a/translated/talk/20180803 What data is too risky for the cloud选题 What data is too risky for the cloud.md b/translated/talk/20180803 What data is too risky for the cloud选题 What data is too risky for the cloud.md
new file mode 100644
index 0000000000..611e3ab2ac
--- /dev/null
+++ b/translated/talk/20180803 What data is too risky for the cloud选题 What data is too risky for the cloud.md	
@@ -0,0 +1,51 @@
+那些数�对于云�说风险太大?
+======
+
+![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003499_01_cloud21x_cc.png?itok=5UwC92dO)
+
+在这个由四部分组�的系列文章中，我们一直在关注�个组织在将�作转�到云时应��的陷阱 - 特别是混�多云环境。
+在第一部分中，我们介�了基本定义以�我们对混�云和多云的看法，确�显示两者之间的分界线。 在第二部分中，我们讨论了三个陷阱中的第一个：为什么�本并�总是�为�移到云的明显动力。 而且，在第三部分中，我们研究了将所有工作负载�移到云的�行性。
+最�，在第四部分中，我们将研究如何处�云中的数�。 您应该将数�移动到云中�？ 多少？ 什么数�在云中起作用，是什么造�移动风险太大？
+
+### 数�... 数�... 数�...
+影�您对云中数�的所有决策的关键因素是确定您的带宽和存储需求。 Gartner预计“数�存储将在2018年�为[1730亿美元] [4]业务�，其中大部分资金浪费在�必�的容�上：“全�公��需优化工作�就�以节�620亿美元的IT�本。� 根�Gartner的研究，令人惊讶的是，公�“为云�务平�支付的费用比他们实际需�的多36％�。
+如果您已�阅读了本系列的�三篇文章，那么您�应该对此感到惊讶。 然而，令人惊讶的是，Gartner的结论是，“如果他们将�务器数�直接转移到云上，�有25％的公�会�钱。�
+等一下......工作负载�以针对云进行优化，但�有一�部分公�会通过将数��移到云�节�资金�？ 这是什么��？
+如果您认为云�供商通常会根�带宽收�费率，那么将所有内部部署数�移至云中很快就会�为�本负担。 有三�情况，公�决定将数�放入云中是值得的：
+  
+  具有存储和应用程�的�个云
+  
+  云中的应用程�，内部存储
+  
+  云中的应用程�和缓存在云中的数�，以�内部存储
+
+
+在第一�情况下，通过将所有内容�留在�个云供应商中��低带宽�本。 但是，这会产生�定，这通常与CIO的云战略或风险防范计划相悖。
+第二�方案仅�留应用程�在云中收集的数�，并将最�值传输到本地存储。 这需�仔细考虑的策略，其中�有使用最少数�的应用程�部署在云中。
+在第三�情况下，数�缓存在云中，应用程�和存储的数�，或存储在内部的“一个事实�。 这�味�分�，人工智能和机器学习�以在内部�行，而无需将数�上传到云�供商，然�在处���返回。 缓存数�仅基于应用程�需求，甚至�以跨多云部署进行缓存。
+
+�获得更多信�，请下载红帽[案例研究] [5]，其中�述了跨混�多云环境的阿姆斯特丹�基浦机场数�，云和部署策略。
+### 数��险
+大多数公�都认识到他们的数�是他们在市场上的专有优势，智能能力。 因此，他们�常仔细地考虑了它的储存地点。
+想象一下这�情况：你是一个零售商，全��大零售商之一。 您已�计划了一段时间的云战略，并决定使用亚马逊的云�务。 �然，[亚马逊购买了Whole Foods] [6]并且正在进入你的市场。
+一夜之间，亚马逊已�增长到零售规模的50％。 您是�信任其零售数�的云？ 如果您的数�已�在亚马逊云中，您会怎么�？ 您是�使用退出策略创建了云计划？ 虽然亚马逊�能永远�会利用您的数�的潜在�解 - 该公�甚至有针对此的�议 - 你能相信今天世界上任何人的��？
+### 陷阱分享，��陷阱
+分享我们在�验中看到的一些陷阱应该有助于您的公�规划更安全，更安全，更�久的云战略。 了解[�本�是明显的激励因素] [2]，[并�一切都应该在云中] [3]，并且您必须在云中有效地管�数��是您�功的关键。
+--------------------------------------------------------------------------------
+
+via: https://opensource.com/article/18/8/data-risky-cloud
+
+作者：[Eric D.Schabell][a]
+选题：[lujun9972](https://github.com/lujun9972)
+译者：[geekmar](https://github.com/geekmar)
+校对：[geekmar](https://github.com/geekmar)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) �誉推出
+
+[a]:https://opensource.com/users/eschabell
+[1]:https://opensource.com/article/18/4/pitfalls-hybrid-multi-cloud
+[2]:https://opensource.com/article/18/6/reasons-move-to-cloud
+[3]:https://opensource.com/article/18/7/why-you-cant-move-everything-cloud
+[4]:http://www.businessinsider.com/companies-waste-62-billion-on-the-cloud-by-paying-for-storage-they-dont-need-according-to-a-report-2017-11
+[5]:https://www.redhat.com/en/resources/amsterdam-airport-schiphol-case-study
+[6]:https://www.forbes.com/sites/ciocentral/2017/06/23/amazon-buys-whole-foods-now-what-the-story-behind-the-story/#33e9cc6be898