[think]数据安全分析不应该想当然


=Start=

缘由:

起因是有个数据安全的case排查,需要对企业内部的GitLab系统日志做分析后给出是否存在异常的结论。现在记录了好几种类型的GitLab日志,但我简单试了试之后发现能对做判断有帮助的当前主要是 gitlab-shell.log 这个日志,其中有个 command 字段的取值主要有 “git-upload-pack” 和 “git-receive-pack” ,虽然从英语字面意思上能猜个大概,但保险起见还是实际测试验证一下,最后发现猜想和实际相去甚远,再结合之前的一些经历和想法,所以简单闲扯几句。

PS:其实很早就发现类似的问题了,但是我好像已经慢慢开始习惯这个现状了(可能和不同人的实际工作状态、习惯有关,不一定是想这样,但体现到实际结果上确实就是这么个情况)。节后这两天相对来说没有那么忙,又就着一个现成的问题再简单记录一下,方便以后回顾。

正文:

参考解答:

网上流传较广的日志字段格式说明:

gitlab-shell.log
**注意:此日志只记录Gitclone协议的操作

……
日志中有价值的信息:

* 同步动作:command:gitaly-receive-pack
* 推送操作:command:gitaly-upload-pack
……

实际测试情况记录:

  • git clone/fetch/pull 在后端shell-log里面记录的是command是 “git-upload-pack” 不要被英文含义给带偏了。
  • git push 在后端shell-log里面记录的是command是 “git-receive-pack” 和clone的含义刚好是反的,不注意研究还真看不出来。

# production_json.log
It contains a structured log for Rails controller requests received from GitLab

# production.log
It contains information about all performed requests

# api_json.log
It helps you see requests made directly to the API

# application.log
It helps you discover events happening in your instance such as user creation and project removal

# application_json.log
It contains the JSON version of the logs in application.log

# gitlab-shell.log
GitLab Shell is used by GitLab for executing Git commands and provide SSH access to Git repositories.
User clone/fetch activity using SSH transport appears in this log as executing git command <gitaly-upload-pack....

个人觉得一个比较理想的数据安全分析流程(SOP)大概是这样的:

  1. 先有需求(需求方可以是老板、业务方、已发生待调查的case、未发生但根据经验极有可能出case的点……);
  2. 再判断需求的合理性,以及可行的解决方案列表,选出当前最合适的一个方案;
  3. 方案定了,需要分析的日志基本也就确定了,剩下的就是寻求日志的官方介绍/说明(对于开源的应用,就是官方文档/甚至是代码;对于内部应用,就是开发同学的说法/相关代码);
  4. 如果已有日志表了,那就申请对应日志表的权限(没有的话就再等等)看看日志的大致情况(数据量级、记录的操作类型、涉及用户量等概况信息);同时也要申请一个相关系统的账号,用于自己登录上去实际看看系统具备的功能,熟悉一下系统的大致功能,同时等有日志了也对比看看你的操作和实际日志记录情况是否符合,如果相符那就最好,如果不相符就需要找开发进一步确认了。
  5. 如果第4步做的比较好的话,其实也就差不多了;但是很多人在第4步只是走了一个过场,领导问看到日志没有?TA说看到了,有日志。领导问日志记录的全不全?TA说每天的日志量都挺大的,应该是全的?一般的领导应该不会再问了,毕竟再问下去就剩自己动手做了,领导自己事情也多,没办法什么都帮你把关;最核心的还是你自己要具备一种打破砂锅问到底的求索精神,事情既然交给你了,你就有责任把事情做好,交付一个好的结果,具体应该怎么做其它人并不关心。

==

  1. 申请相关系统账号,方便必要的时候进行测试和验证;
  2. 申请相关日志权限,了解日志的实际记录情况;
  3. 对照实际测试操作情况检查日志记录情况; #不要想当然,拿实际结果说话
  4. 对照检查OK则通过;否则需要推动开发进行自查自纠,直到对照检查通过为止。 #在开发写日志时也要注意一下命名和实际含义的区别不要太大,比如明明是个下载操作,日志里却有upload的关键字
  5. 还有很重要的一些点(但很多人都会漏掉的):
    梳理并建立一个日志统计大盘,用于了解相关日志的变化趋势,方便事后快速定位问题发生日期; #事出反常必有妖,如果有问题,大盘的某个趋势图中应该能有所体现,如果不能的话那个图可能需要重新画了
    自动定期拨测,通过配置告警实现异常实时通知。 #大盘只有大趋势,拨测可以细化到具体接口/功能,能提供百分比、具体时间段等更细节的信息

参考链接:

https://docs.gitlab.com/ee/administration/logs.html#gitlab-shelllog

gitlab Clone Pull Push 日志信息
https://blog.csdn.net/wyounger/article/details/110956403

上面那篇文章的英文机翻版本
https://developpaper.com/gitlab-clone-pull-push-log-information/ #自动抓取文章并翻译为英文的一个网站,看上去好像还行,但其实不行

git pull 和 git fetch的区别?
https://www.zhihu.com/question/38305012

=END=


《“[think]数据安全分析不应该想当然”》 有 12 条评论

  1. 《好好的数据工具箱——全链路全周期生态共赢价值赋能》
    https://zhuanlan.zhihu.com/p/398082765
    `
    前几天和朋友一起聚餐,当时大家在讨论一个非常质朴的择业问题——数据相关的工作里,如果三选一,是做数据运营好,还是数据分析更好,亦或是做数仓更好?

    小乙觉得:“做运营好,因为运营更贴近一个公司的业务,而业务是公司的核心所在。”
    小华觉得:“数据分析更好,因为这个角色,通常可以从更整体性的视角看待公司的业务。而且现在是数据时代,在这个时代,数据才是公司的核心资产。”
    小姬觉得:“做数仓工程师更好,因为数仓建设才能算是一门真正技术。荒年不饿手艺人,掌握一门过硬的技术,才能在多变的职业生涯中,有自己的不败之地。”

    不过在赞同的同时,好好突然生出一种危机感。在当下有道理的话、有争议的事,在三五年后,会是一番怎样的光景呢?

    “大多数人将职业生涯当做一场短跑比赛。然而事实上,事业生涯是一场至少45年的马拉松。”——《远见》布赖恩•费瑟斯通豪

    无论是选择哪一个岗位,在这样一个变化的时代,仅依靠单一的业务知识、分析能力、或数仓技术到底能不能支撑我们长久的职业发展?

    从需求的角度而言,招聘市场上的JD表明:目前,大多数公司期望的是更复合型的数据人才。
    从供给的角度出发,随着工具的发展,数据科学的应用门槛变得越来越低;数据分析方法与数仓技术,对人们来说变得越来越可及。所以,成为兼具业务知识、分析能力、数仓技术的复合型人才是可行的。
    `

  2. 数据治理:先保证数据质量,再谈数据驱动
    https://mp.weixin.qq.com/s/Zp3URv4sRWU8nsiACwQEKw
    `
    01 — 从DIKW金字塔模型到数据供应链

    要实现数据驱动,重要的是创建一个“数据供应链”,保证数据在从生产、采集、存储、加工、处理,到分析、应用的全过程中的数据质量,并且确保每个过程都是为业务目标而服务的。

    02 — 供给侧:重点关注的数据质量维度

    数据质量问题贯穿整个“数据供应链”。我们经常听到:“垃圾进,垃圾出”,这句话是指高质量数据分析结果,取决于高质量的数据输入,输入的数据质量低下,数据分析结果也叫没有什么价值。以及笔者经常提的“数据治理要从源头抓起”,也是说的这个意思。重点都在强调数据供给侧保障数据质量的重要性。数据供给侧更多的是站在数据生产者或数据管理者的角度看数据质量的,重点关注以下的5个数据质量维度。

    1、数据完整性。
    2、数据准确性。
    3、数据一致性。
    4、数据唯一性。
    5、数据有效性。

    03 — 需求侧:超越准确性的数据质量维度

    从数据供给侧(生产和管理的角度)来看,数据质量主要关注准确性。其目标是尽可能地将数据与现实世界的实体相匹配。通过实施数据清理、修复数据、转换等一系列数据管理工作旨在提高数据准确性。

    04 — 提升企业数据质量的8点建议
    1、业务需求和影响评估
    2、全面盘点和正确描述
    3、数据质量从源头抓起
    4、能选择的时候别输入
    5、建立数据驱动的文化
    6、DataOps——数据运营
    7、数据质量,防大于治
    8、数据质量成效评估

    # end
    数据驱动是依靠数据来赋能决策和运营,高质量数据无疑是实现数据驱动的保证。高质量数据意味着高质量的洞察力、值得信赖的分析报告,可优化的业务流程,更加良好的客户体验和更好的投资回报率。
    `

  3. 如何改进您的数据质量
    https://mp.weixin.qq.com/s/UV3rvB5g1i3fEAP4UQ2KqA
    `
    企业机构每年因糟糕的数据质量而造成的平均损失达到1290万美元。除了直接影响收入外,从长远来看,质量差的数据还会增加数据生态系统的复杂性,进而导致决策失误。
    随着企业越来越多地使用数据分析来帮助推动业务决策,企业日益重视其系统中的数据质量(DQ)。Gartner预测到2022年,70%的企业机构将通过指标来严格追踪数据质量水平并将数据质量提高60%,以此显著降低运营风险和成本。

    数据质量直接关系到决策的质量。高质量的数据能够提供更好的客户线索、对客户的更深入了解和更好的客户关系。数据质量是数据和分析(D&A)领导人需要不断提升的竞争优势。

    1. 确定数据质量改进将如何影响业务决策

    2. 定义“足够好”数据的标准

    3. 建立全企业机构数据质量标准

    4. 尽早并且经常使用数据剖析

    5. 设计和实施用于监测主数据等关键数据资产的数据质量仪表盘

    6. 从基于真实的语义模型转向基于信任的语义模型

    7. 将数据质量列为数据和分析治理委员会会议的议程

    8. 规定数据管理员角色的数据质量责任和操作步骤

    9. 在首席数据官团队或同等机构的领导下,建立一个跨业务部门和IT部门的数据质量专项工作组

    10. 建立数据质量审核作为发布管理的“关口”

    11. 定期向业务部门传达改进数据质量所带来的收益

    12. 充分发挥外部/业内同行团体的作用,例如来自厂商、服务提供商和其他老牌论坛的用户团体
    `

  4. 数据质量管理:6个维度,50个检查项!
    https://mp.weixin.qq.com/s/fzTxhpUglr3pgfAB6OPizA
    `
    01. 数据质量定义
    数据质量的高低代表了该数据满足数据消费者期望的程度,这种程度基于他们对数据的使用预期。数据质量必须是可测量的,把测量的结果转化为可以理解的和可重复的数字,使我们能够在不同对象之间和跨越不同时间进行比较。 数据质量管理是通过计划、实施和控制活动,运用质量管理技术度量、评估、改进和保证数据的恰当使用。

    02. 数据质量维度
    1、准确性:数据不正确或描述对象过期
    2、合规性:数据是否以非标准格式存储
    3、完备性:数据不存在
    4、及时性:关键数据是否能够及时传递到目标位置
    5、一致性:数据冲突
    6、重复性:记录了重复数据

    03. 数据质量分析
    数据质量分析的主要任务就是检查数据中是否存在脏数据,脏数据一般是指不符合要求以及不能直接进行相关分析的数据。脏数据包括以下内容:
    1、缺省值
    2、异常值
    3、不一致的值
    4、重复数据以及含有特殊符号(如#、¥、*)的数据

    04. 数据质量管理
    大多数企业都没有一个很好的数据质量管理的机制,因为他们不理解其数据的价值,并且他们不认为数据是一个组织的资产,而把数据看作创建它的部门领域内的东西。缺乏数据质量管理将导致脏数据、冗余数据、不一致数据、无法整合、性能底下、可用性差、责任缺失、使用系统用户日益不满意IT的性能。
    在做数据分析之前一般都应该初步对数据进行评估。初步数据评估通过数据报告来完成的,数据报告通常在准备把数据存入数据仓库是做一次,它是全面跨数据集的,它描述了数据结构、内容、规则、和关系的概况。通过应用统计方法返回一组关于数据的标准特征,包括数据类型、字段长度、列基数、粒度、值、格式、模式、规则、跨列和跨表的数据关系,以及这些关系的基数。初步评估报告的目的是获得对数据和环境的了解,并对数据的状况进行描述。
    `

  5. 谈数据:数据质量管理的10个最佳实践
    https://mp.weixin.qq.com/s/F7xtDrMSaAFojwua71gIWQ
    `
    数据质量管理需要的是工匠精神,需要不断地对您拥有的数据进行反复“打磨”,循环迭代,将数据治理“常态化”,而不是指望实施一个项目就能实现数据质量的百分百提升。

    关于如何做好数据质量的管理,我们给出以下10条最佳实践,希望对您有所启发。

    01 – 对齐业务目标!

    02 – 评估数据质量

    03 – 分析根本原因

    04 – 制定解决方案

    05 – 控制数据质量

    06 – 纠正数据问题

    07 – 组织体系保障

    08 – 质量考核体系

    09 – 先进技术赋能

    10 – 在数据生命周期中关注数据质量

    数据的生命周期从数据规划开始,中间是一个包括设计、创建、处理、部署、应用、监控、存档、销毁这几个阶段并不断循环的过程。企业的数据质量管理应贯穿数据生命周期的全过程。

    数据规划。从企业战略的角度不断完善企业数据模型的规划,把数据质量管理融入到企业战略中,建立数据治理体系,并融入企业文化中。
    数据设计。推动数据标准化制定和贯彻执行,根据数据标准化要求统一建模管理,统一数据分类、数据编码、数据存储结构,为数据的集成、交换、共享、应用奠定基础。
    数据创建。利用数据模型保证数据结构完整、一致,执行数据标准、规范数据维护过程,加入数据质量检查,从源头系统保证数据的正确性、完整性、唯一性。
    数据使用。利用元数据监控数据使用;利用数据标准保证数据正确;利用数据质量检查加工正确。元数据提供各系统统一的数据模型进行使用,监控数据的来源去向,提供全息的数据地图支持;企业从技术、管理、业务三个方面进行规范,严格执行数据标准,保证数据的规范化输入,标准化。
    `

  6. Informatica:数据质量管理六步法
    https://mp.weixin.qq.com/s/JUWxWU60JrFa0hAtjjvXfQ
    `
    01 – 探查数据的内容、结构和异常

    02 – 建立度量并定义目标
    接下来,需要在关键应用数据字段中明确衡量数据质量的度量标准,并为每个数据字段明确各自的数据质量目标。该度量标准应基于数据质量的以下六个维度:

    * 完整性:哪些数据丢失或不可用?
    * 符合性:哪些数据以非标准格式存储?
    * 一致性:哪些数据值提供相互矛盾的信息?
    * 重复性:哪些数据记录或属性是多余的?
    * 整体性:哪些数据未被引用或遭受其它损害?
    * 准确性:哪些数据是不正确或过时的?

    03 – 定义和实施数据质量规则

    04 – 将数据质量规则构建到数据集成过程中

    05 – 检查异常并完善规则

    06 – 监控数据质量与目标

    笔者一直的观点:数据质量管理需要的是工匠精神,需要不断地对您拥有的数据进行反复“打磨”,循环迭代,将数据治理“常态化”,而不是指望实施一个项目就能实现数据质量的百分百提升。
    `

    The Informatica Data Quality Methodology – A Framework to Achieve Pervasive Data Quality Through Enhanced Business-IT Collaboration
    https://www.informatica.com/downloads/7130-DQ-Methodology-wp-web.pdf
    `
    Step 1: Profile the Data for Content, Structure, and Anomalies
    Step 2: Establish Data Quality Metrics and Define Targets
    Step 3: Design and Implement Data Quality Business Rules
    Step 4: Build Data Quality Rules into Data Integration Processes
    Step 5: Review Exceptions and Refine Rules
    Step 6: Monitor Data Quality Versus Targets
    `

  7. 蚂蚁集团联合权威机构 重磅发布《数据安全复合治理与实践白皮书》【附全文下载】
    https://www.4hou.com/posts/B92W
    `
    2021年12月22日,由中国软件评测中心、国家信息中心《信息安全研究》、蚂蚁集团联合编写的《数据安全复合治理与实践白皮书》正式发布。

    白皮书在对现阶段全球数据安全产业发展格局及治理态势进行充分调研与深度剖析的基础上,从引导企业建设与升级数据安全治理体系的视角出发,以“战略要位、实战牵引、全员参与、技术破局”为核心指导思想,强调数据安全的“复合”治理,即:对治理框架搭建中战略、管理和技术进行统筹规划与设计,形成基线设定、心智运营、原生设计、安全度量、可证溯源、红蓝对抗、测评认证等丰富的治理环节,强化治理过程的联动,将安全与业务复合、管理与技术复合,形成有机整体,充分发挥复合协同效能,构建体系化、准确量化、持续优化的数据安全复合治理模式。

    复合治理模式强调全员参与、原生式安全以及智能化安全运营机制。

    全员参与。数据与业务紧密交织,正是基于这一特点,蚂蚁集团在数据安全的风险管理上一直秉承一个理念:“数据安全不仅是安全团队的事情,而是每个公司员工都需要高度重视的事情”。因此,如何构建一个全员参与的风险治理体系就显得格外重要。蚂蚁集团通过“啄木鸟”行动等丰富、活泼的心智运营活动设计,充分调动全员主动参与积极性,有效实现不同特点人群的精确触达。

    原生式安全。将数据安全的理念和要求融入到研发的过程中,保证产品在发布前已具备充分必要的数据保护措施,而不是出现数据安全问题以后,被动地修复和治理。同时可针对数据处理产品组件开展内部认证,推荐、保障研发团队使用安全、可靠的组件,对使用不符合内部认证标准的组件的产品和系统,督促其及时进行整改,以增强产品和系统的“天然免疫力”。

    建设智能化的安全运营机制,以进一步提升数据安全治理的自动化水平和效率。以红蓝演练为例,通过沉淀自动化、模块化、组件化的红蓝演练能力,制定演练科学投放的策略,并建设全链路风险跟踪能力,形成常态化的红蓝演练机制,从攻防视角更加高效、及时地识别和修复安全风险,实现“以攻促防、攻防相长”的目标。
    `

  8. 心得总结:一名优秀的数据分析专家的能力模型
    https://mp.weixin.qq.com/s/Vgak3QWtvGKjtw4LBz0fYQ
    `
    这两年无论是校招还是社招,数据分析岗位变得越来越卷,两级分化的差异也越来越大。不少应届生吐槽找不到数据相关的好工作,千军万马过独木桥,也见到过今年校招pointer拿到令人惊讶的40w、50w、甚至是60w的校招数据/策略offer。薪资一下子就碾压工作4-5年的数据后浪们。

    一部分人过得水深火热,一部分人又平步青云。

    一部分人觉得数据相关职业太过内卷,竞争激烈。一部分人又觉得数据相关职业至少比传统岗位好,在未来数字化时代下,各行各业都需要数据分析从业者,十年内都不会失业,是妥妥的朝阳职业。

    但有一点大家形成了共识,那就是随着数据从业者越来越多,向上通道变得越发激烈。什么意思呢?通俗来讲,你想从数据分析师往上升职,没那么容易了,是超级难了。如果你想从数据分析师成为一名数据分析专家,那可能不仅仅需要扎实的数据技能功底,还要考虑各项综合能力,你才有机会往上走。

    这让我不禁思考一名优秀的数据分析专家需要有什么样的能力模型呢?

    到底什么才是你成为数据分析专家的差异化特质?
    ==

    数据分析专家能力模型

    招式:懂商业(业务能力)
    LEVE1,业务洞察
    LEVE2,策略分析
    LEVE3,战略布局

    兵器:懂数据(技术能力)
    LEVE1,数据获取能力
    LEVE2,数据分析能力
    LEVE3,数据架构能力

    心法:懂分析(逻辑能力)
    LEVE1,问题定义清晰
    LEVE2,框架逻辑严密
    LEVE3,思考全面系统

    气功:懂汇报(沟通能力)
    LEVE1,明确分析结论
    LEVE2,高效表达沟通
    LEVE3,数据解决方案
    `

  9. https://docs.gitlab.com/ee/administration/logs.html#production_jsonlog
    `
    production_json.log # 也不确认通过终端SSH协议进行的仓库下载行为,会不会记录在这个日志里面(但肯定会在gitlab-shell.log日志里,不过就麻烦一些了)
    {

    “format”:”html”, // 当format是zip的时候一般就是web页面的下载行为
    “action”:”show”, // 此时的action值为archive
    “meta_caller_id”:”Projects::IssuesController”,

    }
    `

  10. Data Science Culture Doc – 数据科学家的团队文化
    https://bytepawn.com/data-science-culture-doc.html
    `
    # Introduction
    I wrote a Culture Doc for the Data Science team I lead. It consists of 24 values (or slogans) that is a good representation of what we believe, what we want to achieve, and how we want to get there.

    It’s no secret that a lot of the values are taken from other companies’ culture docs (mainly Facebook and Amazon), with some re-wording; some of them are original.

    The best-way to read is on the Data Science Culture mini-site, and I have also reproduced the document below.

    Data Science Culture Doc

    The goal of this document is to solidify our culture by writing it down. The goal is not to create it — you cannot create culture by writing it down. Culture is people’s existing everyday behaviour and communication, and which of those is rewarded by the organization.

    Some of the phrasing we shamelessly stole from other companies’ culture docs. As long as we’re also living these values, it’s fine. And Great artists steal is one of our values.

    # Mission-使命

    ## Focus on impact.
    Jeff Bezos has said “customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great”. We believe that in the long-term Data Science can make customers more satisfied, make customers like our products more and in the process improve our revenues significantly.

    ## Data is the new oil.
    We have billions of rows of data about millions of customers. As long as our customers are receiving static emails about irrelevant offerings, can’t find what they’re looking for in our stores or struggle with widgets they never use in our apps — there is oil in the ground.

    ## Our goal is not to get people to like us.
    Our goal is to get customers to like our company’s products. We are not our users. We build products that benefit the customer in the end.

    ## We ❤ ️experiments
    To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment.

    ## Customers are more than data.
    Build products around and for people, not data. We must never forget that data is a means to an end, and the “end” is to create better experiences for people.

    ## Data wins arguments. Data enables us to win.
    Data beats talking. Data beats slides. Data beats ties. Data beats being popular. Many of the important decisions we make can be made with data. A team making rational, high-quality decisions based on data and experiments will light a bonfire.

    ## If we don’t create the next version of our services, somebody else will.
    We face great competition in the marketplace. Our team also faces great competition internally.

    ## Do things that feel right. Measure beyond numbers.
    It is dangerous to think everything can be measured, because it leads us to believe everything that cannot be measured isn’t real. Emotions, feelings are real. People are not deterministic black boxes, nor independent, identically distributed random variables. People think, talk and feel. Building a sustainable brand means winning the trust, hearts and minds of people, not just their compulsive clicks (and buys).

    # Tactics-战术

    ## Great artists copy.
    Steve Jobs invented the computer mouse by copying the idea from Xerox. We live with open eyes and an open mind and adopt good ideas we see elsewhere.

    ## Do more with less.
    Constraints breed resourcefulness, self-sufficiency and invention. We use simple but powerful tools to get our work done. There are no extra points for growing headcount or budget.

    ## There is no point in having a 5 year plan.
    Our industry is changing at a breakneck speed. We should have a 6 month plan, and know where we want to be in 5 years. And every 6 month, we take another look at where we are.

    ## Ruthless prioritization.
    Picking the right problem is more important than being able to solve problems. Focus on solving big problems. Focus on helping the most customers.

    ## Stay focused and keep shipping.
    Your product doesn’t exist until it ships. And if it doesn’t exist, it cannot have an impact. It doesn’t matter how great your idea is if nobody is using it.

    ## The quick shall inherit the earth.
    Fast is better than slow. Fast means it’s out in the real world. That means fast can learn from experience while slow can only theorize.

    ## We treat reversible decisions as experiments.
    Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation (for example, picking the location of a new Carrefour hypermarket). But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors (for example, the way we do code reviews). We don’t have to live with the consequences for that long. We can reopen the door and go back through.

    ## Done is better than perfect.
    Building a good enough product and shipping in 3 months is almost ways better than waiting to release the first version in 12 months. The learning and feedback from users in those 9 months will enable us to build a much better product in the end.

    # Team-团队

    ## Hire and develop the best.
    We maintain a high bar and hire the best people to solve hard problems. You’re good at what you do. The person in your team is also good at what they do. Insist on high standards. Talk to others. Don’t pay too much attention to seniority and rank.

    ## Clear, concise and consistent writing.
    Good writing gets ideas noticed. It’s not true that only ideas matter. If your writing is sloppy, people will think you are the same. They won’t care about your message, they won’t work with you.

    ## We are distributed.
    We are a distributed team working from 5+ countries. We must be able to communicate efficiently online using asynchronous channels, while also creating opportunities to come together regularly and socialize. We prefer informal written communication (chat) to meetings and emails.

    ## Always be learning and teaching.
    We are some of the luckiest humans to ever be alive. We work in a high-demand field at the intersection of some of the most intellectually stimulating disciplines, and this field is continuously improving and re-inventing itself. We must always be reading and learning to keep up, and help others to learn and keep up. But, this is not a problem for us, since it’s great fun.

    ## We ❤ ️failures.
    When something goes wrong, we don’t blame each other, we remain patient, but quickly fix the problem. We do a post-mortem, identify root causes and look for systemic improvements. We do this for both social and technical issues.

    ## We are not good at everything.
    We don’t have to be good at everything. For example, we are not good at Objective-C development or writing marketing copy, and we can be honest about it.

    ## We trust each other.
    We listen attentively, speak candidly, and treat others respectfully. We are vocally self-critical, even when doing so is awkward or embarrassing. We prefer transparency over office politics and information silos.

    ## A team of humans.
    We come together everyday to solve interesting problems, not to go skiing. We are a beautifully diverse team from many cultures, countries, religions, languages and family backgrounds. We respect each other, we help each other and we have fun while we solve our interesting problems. We serve each other and other teams.
    `

  11. 微信万亿数据仓库架构设计与实现
    https://mp.weixin.qq.com/s/E0X7094kk9My7JTEOELjDg
    `
    几点想法:
    1. 企业安全想要做的好,工程化能力一定要足够强,否则也是”无根之木,无源之水,无稽之谈”,想法再好也需要平台技术来支撑,提高效率,将能力价值最大化。
    2. 好的架构不是设计出来的,是逐步演进出来的,而且架构其实也没有好坏一说,只有是否合适一说,再高大上的设计如果不能匹配当前的环境也是无效的。
    3. 数据的质量是基础,如果数据质量不行,最终的结果一定是“garbage in, garbage out”,没有例外。
    4. 除了初始的数据质量要保证,后续的每一个处理环节其实也需要保证,因此建立一个针对性强、有效的质量保障体系到了中后期是一个非常关键的点,否则系统会存在逐渐劣化的可能和趋势。

    ==
    没有足够的特征数据,安全策略将是”无根之木,无源之水”。微信安全数据仓库应运而生,成为整个安全业务的特征数据存储中心,每天服务了万亿级的特征数据读写请求,为整个微信安全策略提供了可靠的数据支撑,是微信安全基石之所在。然而,微信安全数据仓库不仅仅是一个存储中心,更是一个特征管理和数据质量管理的中心。在演进过程中,数据仓库一直致力于提升特征管理能力和数据质量保障,实现了特征的管理、共享、分析和数据质量检测等功能。本文将介绍安全数据仓库的起源、演进、当前的架构设计和数据质量保证系统的实现。

    # 安全策略开发流程
    安全业务的核心逻辑在安全策略中实现。整个的策略开发流程包括特征数据的收集,安全策略的编写实现,和策略的反馈评估。其中特征数据的收集是必不可少的环节,数据的质量将直接影响安全策略的效果。

    # 安全业务后台架构
    当前我们已经把所有的安全策略统一到安全策略平台进行开发和管理,特征数据的接入和计算统一到了Flink实时计算平台和特征平台。

    数据仓库作为承上启下的部分,对上为在安全策略平台上的安全策略提供了数据读写,对下为实时计算平台和特征平台计算输出的特征提供了存储,是整个业务体系中不可或缺的部分。

    安全业务特征数据主要有2种类型:
    * 离线特征:用来满足离线计算数据导入线上实时使用的需求,通常特征离线计算,定期的批量后台上线,提供在线读,但不支持实时写入。
    * 实时特征:用来满足实时的在线读写需求

    离线KV适合离线特征要求的场景,拥有非常好的读性能,并且提供了版本管理功能,在处理有问题数据时可以非常方便的可以回退版本,采用这种KV存储时,value一般是protobuf对象,新增特征时可以在pb中增加字段。

    实时KV适合实时特征的场景,在线实时读写性能优秀,而且支持数据过期淘汰,该KV提供了类MySQL表的概念,KV表定义类似于一个MySQL表,而每一个安全业务特征刚好可以用表的一个字段表示。

    离线特征数据同步:离线特征数据上线流程是通过离线计算在文件系统中生成一个文件,然后将文件导入到离线KV,而离线KV支持多个IDC共享同一份数据,数据文件只需要生成一份,所有IDC的离线KV拉取同一个文件,新数据最终能同步到所有IDC上。

    实时特征数据同步:实时特征的同步采用微信自研的分布式队列组件,该组件提供了高可靠、高可用、高吞吐、低延时的数据消息队列服务。数据仓库写接入模块在写入数据时,同时将数据写一份到分布式队列,使用队列做跨IDC的数据同步,在其他IDC启动进程消费队列中的数据,写入到本IDC的实时KV,实现实时特征数据的同步。

    # 数据质量保障
    数据仓库主要通过两个方面来保障数据质量:特征的标准化和数据空跑系统。

    离线特征数据来自于业务离线计算在分布式文件系统中生成数据文件,然后将文件上线。历史上曾因为生成的数据文件存在错误,存在错误的文件数据被上线到离线KV,导致策略出现故障。为了保障离线特征数据的质量,数据仓库设计了一套空跑系统,在上线前对数据文件进行检查,避免存在问题的数据上线到现网。

    完整的数据上线流程如下图,空跑差异检测通过后,需要检查数据文件完整性,防止文件被修改或者覆盖,最后数据再上线到现网数据仓库系统,通知业务数据上线成功。如果中间任何一个步骤出错将告警给业务负责人,提醒人工介入处理。

    # 总结

    数据仓库将分散的特征全部集中统一管理,提供统一的访问接口,标准化每个一个特征,建立了统一的规范,并且在此基础保障了数据的质量,夯实了整个安全业务的基础,助力一站式的数据-策略开发,极大的提升了安全对抗的效率,实现了数据价值的最大化。
    `

  12. `
    # production_json.log
    It contains a structured log for Rails controller requests received from GitLab. Requests from the API are logged to a separate file in api_json.log.

    User clone and fetch activity using HTTP transport appears in the log as action: git_upload_pack.

    and action = ‘git_upload_pack’

    # api_json.log
    It helps you see requests made directly to the API.

    and params like ‘%”git-upload-pack”%’

    # gitlab-shell.log

    GitLab Shell is used by GitLab for executing Git commands and provide SSH access to Git repositories.

    and command = ‘git-upload-pack’
    `
    在上面3个GitLab记录的日志里面,查询代码下载操作所用的条件是不一样的。这个需要注意。
    https://docs.gitlab.com/ee/administration/logs/#gitlab-shelllog

回复 abc 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注