要理解DataSecOps，首先要理解DevOps。
DevOps的一个紧张驱动力是云的弹性，软件组织可以在云中连续支配软件。
因此，他们可以在小范围内推进，快速失落败，并更快地创新。

然而，DevOps面临着几个常见的安全问题。
许多公司有一个DevOps团队，但他们并不能采取DevOps的思维办法。
也有缺点配置和变更管理的问题，这可能导致安全即补丁的高本钱。
因此，安全须要被陪衬到DevOps中，并嵌入到流程中，因此有了这个词 DevSecOps.

展望数据领域，本认为 "数据民主是最糟糕的数据管理形式，除了所有其他形式。
"

数据民主化是不好的，由于它对大多数组织来说是一个很大的任务。
总是会有掌握权的损失，风险的增加，数据保护、隐私和合纪律例的激增，以及操作上的寻衅。
但是，数据民主化也可以是好事，由于它许可组织内更多的人以新颖的办法利用数据，缩短数据的代价实现韶光，从而带来商业代价。

公司已经开始在各种功能中采取数据民主化，如报告、商业智能和预测剖析，并以新的云技能作为助推器。
然而，这样的采取过程每每会花费大量的财政资源。

DataOps是对全体组织内不断变革的数据及其用户的敏捷折衷。
与传统的DevOps比较，DataOps被更多的团队（尤其是商业用户）利用，并且更加强调隐私和数据管理，但也大多不太成熟。

DataSecOps是数据民主化的真正推动者。
在DataSecOps的思维中，更多的数据消费者意味着更高的数据暴露风险。
小型数据根本举动步伐和安全团队正在处理大量的数据和数据变革。
因此，你不应该大大减慢代价实现的韶光，但也不应该对安全需求做出妥协。
你须要一个整体的、协作的心态和任务，而不是特定的团队。

以下是基本的DataSecOps原则。

安全须要成为数据运营的一个持续部分，而不是事后才想到的。
任何临时性的过程都须要转变为持续性的。
须要将环境、测试和自动化明确分开。
确定优先次序是关键--紧张针对敏感数据。
数据是明确拥有的。
数据访问该当是简化和确定的。

Ben用一些关于如何开始在你的数据堆栈中嵌入安全的条记来结束这次发言。
首先，你须要用适当的资源让测试和自动化得到尊重。
然后，你该当在数据项目中包括安全团队。
末了，你该当总是喜好连续的过程而不是临时的项目。

10 - Insights-as-a-Service: Creating Data Products from your Customers’ Data

在传统的内部当代数据栈（MDS）中，密钥是可用的。
用例是可预测的。
架构哀求是线性的。
数据量以一种已知的速率增长。
利益干系者可以达成同等。
组织层次是明显的。

然而，外部的当代数据栈（MDS）则相反。
关键是不费吹灰之力就能得到。
用例是相对未知的。
架构哀求是高度可变的。
数据源被遮蔽，并以难以计数的速率增长。
培植者与利益干系者有一定程度的分离。
组织层次是定制的。

因此，办理方案是一个灵巧的架构，具有支持细微差别的定制选项。
但是，我们如何才能平衡呢？授予太多的灵巧性和定制化将表示出对技能专长和繁芜的入职过程的需求。
它的掩护也将更具寻衅性。
给予太少的灵巧性会使你的办理方案很快达到可扩展性的限定，而客户会离开。

Aaron Peabody认为，坚实的数据运营实践为达到这种平衡供应了最佳的效益，并成为洞察力即做事（IaaS）的根本。
DataOps的六个核心支柱包括认证和数据入职、分区和安全、事情流和管道折衷、数据质量和真实性、可重复性和冗余、CI/CD和可不雅观察性。

API经济为工程供应了一个新的范式。
这种转变哀求我们批驳性地核阅我们该当和不应该为任何特定项目建立什么。

在旧的办法中，我们被教导要建造它、采购它、购买它。
因此，薄弱性始终是一种风险。
在新的办法中，我们购买它、采购它、建造它。
功能限定可能是一种风险，但上风包括规模、速率和支持。

通过以精确的办法建立一个外部MDS，就能使 Untitled Platform不仅仅是一个外部MDS运用。
它还包含支持创建和支配内部和外部MDS运用程序的根本举动步伐。
它在MDS生态系统中的浸染是成为支配的领导者。

随后，Aaron深入磋商了Untitled平台在设计时考虑的数据运营根本。

对付认证和数据入库，该平台利用。

由Fivetran供应的普通数据源连接和集成管理。
Auth0用于根本举动步伐连接和联合内部/外部做事桥。

对付分区和安全，该平台利用。

AWS组织和账户架构。
每个客户都有一个独特的AWS账户用于平台后台，与我们的根组织架构相连接。
模式和数据模型。
客户在全体数据层有自己独特或独立的模式和存储位置。
多租户位置被隔离并用于客户选择的特定产品。
行级安全和安全组。
对付伶仃的多租户地点，我们利用工具、列和行级安全分区，通过Auth0和Dynamo ARN表在全体平台供应的生态系统中进行联合。

对付事情流程和管道折衷，该平台利用。

亚马逊EventBridge。
EventBridge作为一个核心路由决策引擎，适用于构成支配生态系统的所有微做事。
这种模式确保以最佳的TCO得到最高的性能结果，并将根本举动步伐事宜与依赖的数据事情事宜解耦。
Airflow。
通过事宜流和AWS Lambdas触发的DAG，在参数存储中为独特的客户设置了折衷规格。
DAGs为每个dbt模型运行两个任务（dbt-run和dbt-test），虔诚于Airflow的原子方法。
dbt：通过BashOperator调用的dbt。
DAGs在主仓库和客户仓库中启动dbt任务运行。
事情被排序为逻辑线，并通过来源、分期转换和市场模型进行依赖。
Snowflake。
这是Untitled平台的主数据存储，它为其嵌入式商业智能产品和ML办理方案供应动力。

对付数据的质量和真实性，该平台利用。

dbt包和测试。
包库路径和数据源都有特定的模板，在根Untitled dbt GitHub repo中管理。
每个dbt项目和包清单都是在平台账户设置过程中组装的。
每个客户有一个 repo，依赖于其主源库的更新。
包是预先配置了测试自动化和表格文档的。
Untitled作为自定义源映射引导。
如何处理那些你没有支持模式和管道的数据？ Castor Docs用于全面的数据文档、转换脉络和管理方案。

对付可重复性、冗余性和可不雅观察性，该平台利用。

Terraform（外部做事），它折衷Fivetran支配架构和配置、Snowflake架构、角色、用户和政策配置、支持的目的地的替代客户仓库和云根本举动步伐以及Auth0租户架构。
亚马逊Cloudformation（内部做事），支持AWS组织账户架构、AWS角色、用户和策略配置，以及AWS做事、API和参数存储。
New Relic，使他们能够看到系统遥测数据和摄取全体根本举动步伐生态系统的事宜馈送。
有自动非常标记和事情流程，用于主动管理支配，以及向客户供应的关于其自身支配的子账户报告的有限视图。
GitHub + CircleCI：所有核心根本举动步伐即代码的内部和外部模块都在主组织库中，包括特定的工具模板。
客户组织被创建或桥接，根据利用情形和账户创建或修正过程中产生的配置设置克隆核心库，并依赖于主库。

将这统统结合起来，Untitled平台是技能不可知的，供应了数据源和MDS工具的特定模板，实现了现成的可选性，并终极统一了DataOps和IaaS平台。

团队领导11 - Breaking Your Data Team Out of the Service Trap

Emilie Schario，曾经是Netlify的数据总监，他在会议上揭橥了最激情亲切的演讲。
The data stack at Netlify看起来像下面这个。

他们利用定制的 Python 脚本、Meltano 和 Fivetran 将数据移入 Snowflake 数据仓库。
他们利用 dbt 来转换 Snowflake 中的数据，利用 dbt 云来折衷 dbt 事情。
他们利用Transform作为指标存储，Census用于运营剖析，Mode用于BI，Airflow用于折衷全体架构。

大多数人认为，建立一个数据团队意味着真正快速地拉动一个数字，但事实上，远不止这些：见告人们不要，管理全体业务的竞争性优先事变，说服人们在他们想要的数据之前追踪事情，等等。

Emilie强调，任何数据团队的目的都是为了帮助组织做出更好的决策。
Netlify的数据团队的义务是通过供应准确、及时和有用的洞察力，使全体组织能够做出最好的决定。

不幸的是，大多数数据团队都是失落败的。

数据团队被各种问题轰炸着。
我们的新用户是从哪里来的？这个新功能的采取情形是若何的？哪个营销来源产生的CAC最低？ 但人们并不信赖数据团队的事情。
三分之一的实行高管不相信他们用来做决策的数据。
50% 的知识工人的韶光被摧残浪费蹂躏在猎取数据和探求他们不信赖的数据的确认来源上。
85%的大数据投资被认为是摧残浪费蹂躏的。

为什么？数据团队陷入了悲哀的恶性循环中。

团队急于推出剖析报告，由于有太多的事情要做。
期望塑造了 利益干系者对他们所得到的印象。
如果不符合预期，利益干系者就会质疑剖析质量，以是数据团队就会花大量的韶光来 "证明 "数字。
由于积压的 "证明 "数字和现有的技能债务， 团队无法开展新事情。

Emilie认为造成这种问题的根本缘故原由是，数据团队被看作是做事组织（问题进来，答案出去），就像IT组织。
这是有问题的，由于数据团队被困在一个被动的位置，而不是一个主动的位置。
他们不是在创造洞察力，而是在回答问题。
但这并不是数据团队的目标。

做事模式都是缺点的，由于如果我们把所有的韶光都花在回答问题上，我们将永久不会交付洞察力（类似于一个陷在会议中的工程师永久没有韶光来编码）。
如果我们根据我们供应的洞察力来定义团队，我们就须要专注于供应洞察力，而不仅仅是回答问题。

这并不虞味着我们把做事模式扔出窗外。
与其将我们的数据团队培植成做事机构，不如将我们的事情重塑为构建一个数据产品使企业能够做出更好的决策。
但人们有时不知道数据作为一种产品在实践中意味着什么。

一个范例的数据团队做五种类型的事情。
运营剖析，指标管理，数据洞察，实验报告，以及为他人做事。
你的数据团队也会做其他事情，但我们的重点是影响。

运营剖析意味着将数据从X系统转移到Y系统，Netlify为此利用了Census。
这有助于增加全体公司对数据的访问，改进业务流程。
指标管理意味着对特定的关键绩效指标拥有所有权，包括能够根据须要对其进行切分，并真正理解正在发生的事情。
Netlify在这方面利用Transform。
这有助于减少对已经存在的指标的重复哀求（自我做事）。
数据洞察力。
这里的问题是，人们不知道他们不知道的关于他们的用户，他们可以在数据中找到。
"Netlify发布了一本名为 "Insights Feed "的内部手册，以帮助创造关键的计策杠杆（阅读Paige Berry的"Sharing Your Data Insights to Engage Your Colleagues"的文章理解更多信息）。
此外，他们建立了一个洞察力中央，作为他们事情的机构影象。
这个中央帮助人们加入到数据团队的事情中（与他们在组织中的角色无关），并将标题作为关键的收成，让人们能够略读并提炼出他们所学到的东西。
实验报告。
产品/增长/营销团队常常想理解他们的实验是如何进行的。
这些实验有助于改进激活、转换、保留和货币化。
在Netlify，每个实验都须要单独剖析，他们目前正在探索Eppo。
为他人做事意味着为同事的问题供应答案。
Netlify利用GitHub进行要乞降Mode进行剖析。
这样的做法有助于授权给有数据依据的决策。
纵然在为他人做事时，你也要把他们的问题翻出来。
用户故事可以帮助浮出水面，挖掘洞察力。

如果你要从头开始建立一个数据团队，Emilie建议从左到右进行。

业务剖析。
首先，将数据放在其他系统中，并使其易于访问。
这将使你能够边走边操作数据。
关键绩效指标/衡量标准。
确定你的入站哀求是什么。
创建你可以设置的指标，并让人们节制这些指标的所有权。
在现有事情的根本上，将指标放在人们已经在事情的系统中（例如，SFDC中的产品利用指标）。
数据洞察力。
将你在***联播（Slack频道）中创造的信息浮现给你的组织。
大声事情。
你的事情只有在人们知道的情形下才能产生影响。
实验报告。
建议对定价页面的拟议变革进行A/B测试。
志愿做剖析。
广泛分享结果。
教授MDE、统计学意义和干系的关键术语。
为他人做事。
通过专注于高影响力的事情，人们会对等待哀求更加宽容。
如果你专注于精确的计策重点，你也会领先于哀求。

你的 data team structure该当像下面这样，你的数据团队中的每个人都该当向一个数据领导报告。
每个数据团队成员该当有权拥有一个理解你事情的经理。
要乞降优先级的确定是与组织中的其他业务伙伴一起进行的。

此外，你的数据团队须要资源。

人数。
3-10%的公司该当专注于数据和决策。
预算和人数必须随着组织的发展而增加。
资金 - 职员。
如果一个人专门卖力一个特定的领域，如产品或财务，他们的人数该当由该领域供应资金。
让其他人来分享数据团队供应的代价。
资金 - 工具。
确保你的工具是为你事情而不是反对你。
探求那些从数据组织的代价中受益的互助伙伴来帮助帮助。

如果你正在旋转一个挣扎的团队，埃米莉推举了这些技巧。

利用Slack来开始改变数据文化。
创建一个#data-reads频道，分享干系的文章/通讯，以帮助建立一个数据文化的文化。
在一个可以持续的地方分享你的数据见地（比如内部博客），同时也在人们事情的地方分享Slack，并附上内部博客的链接。
在企业的其他部分探求互助伙伴。
与用户体验研究团队互助。
实行资助商参与到一个习气性的循环中。
将 "数据先容 "作为你入职培训的一部分。
举办办公韶光，人们可以提出问题。
专注于做事好的较少的团队。
优先考虑主动的洞察力。
每周抽出2-3个小时的深度事情。
在这个韶光窗口里，只做你能找到的事情。
大声分享你所创造的东西。
洞察力是你的开胃菜。
它们很小，但可以导致更大的东西。

为了衡量成功，你 don’t want to tell your data team’s ROI story.数据团队的代价是你所匆匆成的决策的数目和数量的函数，而不是你所拥有的数据或你所建立的仪表盘。
你要衡量的是业务影响，而不是产出（通过洞察力开始的事情所带来的收入提升，或通过有针对性的沟通来提高入职的产量）。
考虑丈量整体满意度的NPS。

12 - Improving ROI with Snowflake + Fivetran

以下是传统数据管道的三个紧张寻衅

伶仃的和多样化的数据。
数据以不同的形状和形式涌现，有多种整合办法。
可靠性和性能低落。
数据管道常常断裂，而且由于数据随韶光变革，数据转换很慢。
繁芜的管道架构。
这种架构须要许多工具、定制代码和不同的技能组合。

有了 Snowflake 数据云，事情就不同了。
Snowflake是一个环球统一的系统，将公司和数据供应商与他们的业务最干系的数据连接起来。
Carlos Bouloy强调数据云的好处。

访问。
你可以在数据云中得到第三方数据、生态系统数据和组织数据的访问权。
管理。
你可以轻松地保护、解锁和理解你的数据。
行动。
产品团队、数据科学家、剖析师和其他业务团队可以对数据采纳行动。

Snowflake data cloud platform支持数据工程、数据湖、数据仓库、数据科学、数据运用和数据共享。
它与互助伙伴数据、第三方数据、SaaS数据、运用数据、客户数据和数据做事一起事情。

它对任何事情负载都是快速的。
在所有用户和数据量上快速可靠地运行任何数量或类型的作业。
它只是事情。
用自动化取代人工，实现规模化运作，优化本钱，并最大限度地减少停机韶光。
它与主要的东西相连。
在团队、事情负载、云和数据之间无缝和安全地扩展访问和协作。

Snowflake、Fivetran 和 dbt 的组合是强大的。
Fivetran 是自动数据集成，许可访问 SaaS 办理方案（Netsuite、Marketo、Jira、 Stripe 等）。
它可以与传统的数据源如SQL Server、Oracle等一起事情。
它使您能够轻松地让您的数据进入数据云，而无需处理繁芜的流程和开拓周期。
一旦数据进入 Snowflake，您可以通过运行 dbt 事情来实行 ELT 过程。
一旦数据被转换，您的数据从业者可以在数据云中利用这些数据。

总的来说，这种组合可以帮助你轻松连接和加载数据，提高管道的可靠性和性能，并降落管道的繁芜性。

13 - Increase Data Productivity by Extending Self-Service Analytics to Business Teams

大多数组织仍在努力培养一种数据驱动的文化。
德勤2019年的一份报告创造，67%的高管不习气利用他们目前的工具来访问数据。
另一份来自NewVantage Partners的2021年报告创造，只有25%的人认为他们已经铸造了一种数据文化，24%的人认为他们已经创建了一个数据驱动的组织。

Julie Lemieux认为，对人友好的剖析堆栈会促进自助做事文化。
有五种方法来设计一个人类会真正利用的剖析堆栈，使你的数据民主化倡议得到成功。

用数据目录将数据翻译成商业术语。
通过使剖析员在全体剖析生命周期中在同一运用环境中事情，保持剖析流状态。
通过拥有一个直不雅观和随意马虎配置的用户界面，像人一样思考（和事情）。
利用户能够为他们的剖析增加更多的数据（而不是更多的问题）。
用强大的可视化手段促进（数据）讲故事的艺术。

任何自助式剖析文化的根本是一个堆栈，它与其他业务团队常用的其他工具一样，对人友好且灵巧。
让数据剖析变得民平易近和可用，将引发人们的好奇心，人们将乐于探索数据，而不是被它吓倒。
通过肃清长期以来横亘在他们和数据之间的障碍，你会很高兴地看到有多少人准备好行使这种好奇心并加入数据对话。

Nelson Cheung然后供应了一个关于在Clover建立自助剖析文化的利用案例。
Nelson的数据剖析团队为Clover团队开拓工具和做事，以做出数据驱动的决策。
就背景而言，Clover为商户建立了一个硬件和软件办理方案的生态系统，以帮助他们经营业务。

他磋商的有四个紧张部分。

充分利用云技能。
他们在早期的 DevOps 资源有限。
后来，他们采取了Snowflake的云托管办理方案，使他们能够花更多的韶光与业务利益干系者，灵巧地配置各种事情负载的打算资源，并与其他剖析工具进行本地整合。
采取为自助做事设计的工具。
他们理解到，某些工具更适宜授权给用户，让他们自己得到利用数据和进行自定义剖析。
他们选择了Heap Analytics来网络用户的互动，而Sigma Computing则对数据进行可视化/剖析。
认识到用户在其自助做事旅程中的位置。
他们将用户分为4个阶段。
第一次利用（"我须要帮助。
你有韶光和我一起坐下来，一步步地进行吗？"），Spreadsheet Pro（"只要给我指出数据，我可以从那里开始。
"），Super User（"一旦触发了一个阈值，我可以创建一个自动的电子邮件关照？真棒！
"），以及 "倡导者"（"一旦触发阈值，我可以创建一个自动电子邮件关照？"），以及倡导者（"你须要将这些数据在一段韶光内可视化？ 我可以帮忙！
"）。
构建办理方案，使每个用户都能在他们的旅程中发挥浸染。
这些办理方案包括为首次利用的用户供应YouTube教程，为电子表格专家供应Sigma/Snowflake/Spreadsheet表格，以及为超级用户供应剖析事情流程样本。
倡导者在他们的旅程中取得的进展得到了支持和赞许。
14 - Why Don’t These Numbers Match? Why Information Architecture Matters in Analytics

数字不匹配是许多剖析团队常常处理的一个问题。
为什么这些收入数字不匹配？为什么上周的收入低落了？哪个数字是精确的？ Jacob Frackson和 Callie White认为，选择适当的信息架构是处理这一问题的最佳办理方案。

信息架构不好的公司的属性是。
衡量标准的命名因此先来后到为根本的。
每个人对 "最新 "都 有不同的观点 数据掩护者更方向于增加新的栏目而不是更新现有的栏目。
这些都会导致沟通不畅，无处不在。
具有良好信息架构的公司的属性是。
衡量标准的命名是协作性的。
"最新的 "是由数据掩护者定义的。
数据掩护者积极思考剖析的用户体验。
沟通是根据人物的背景进行的。

设计一个强大的信息架构的最佳实践可以分为两类：角色和工具。

关于角色，你该当能够回答以下问题。

你的角色是什么？随着韶光的推移，这些将如何变革？ 谁是这些角色中的管理人/权力利用者？考虑到他们的权力利用者，哪些角色该当被优先考虑？ 这些角色利用什么措辞？我们能不能符合这个标准，或者这与我们的大架构有冲突？ 数据或信息的运用是什么？该运用是更多的技能性还是更多的一样平常用场？

关于工具，你该当能够回答以下问题。

你如何表明你的数据的及时性或准确性？你如何表明哪些仪表盘和表格是最新的，哪些是废弃的？ 用户如何理解数据或可视化的周围环境？如何确保他们对数据的阐明是精确的？有没有一种措辞，你可以利用足够的高下文来准确传达信息？

对付角色和工具，你该当不断思考用户体验是什么，掩护者的体验是什么，以及你如何通过信息架构来简化或改进这些体验。