业务常见词语
tbghg

[TOC]

Git 团队协作中使用的术语

比较常用的是WIP、LGTM、CC

  • WIP   Work in progress, do not merge yet. // 开发中
  • LGTM Looks good to me. // Riview 完别人的 PR ,没有问题
  • PTAL Please take a look. // 帮我看下,一般都是请别人 review 自己的 PR
  • CC Carbon copy // 一般代表抄送别人的意思
  • RFC  —  request for comments. // 我觉得这个想法很好, 我们来一起讨论下
  • IIRC  —  if I recall correctly. // 如果我没记错
  • ACK  —  acknowledgement. // 我确认了或者我接受了,我承认了
  • NACK/NAK — negative acknowledgement. // 我不同意

技术方面常见的词语

  • CS:案例研究(CaseStudy),一般指出现故障后的学习与反思,case可以理解为出现的故障
  • Oncall:值班
  • LB:负载均衡(Load Balancing)
  • SLB:服务器负载均衡器(Server Load Balancer)
  • DS:分布式存储(Distributed Storage)
  • SRE:网站可靠性工程师(Site Reliability Engineer)
  • SLO:服务水平目标(Service Level Objective)用于描述和衡量服务质量的手段。SLO 可以是服务质量的各种指标,例如服务可用性、服务性能、服务容错性等等。通常可以基于服务质量的历史数据,对 SLO 进行设定和调整,并通过监测指标变化来检测服务质量是否达到预期的 SLO 水平,及时发现和排查异常,以确保服务一直保持高水平的稳定性和可靠性,同时也是评估服务质量表现的重要指标。
  • XSS:跨站脚本攻击(Cross-Site Scripting)
  • CSRF:跨站请求伪造(Cross-Site Request Forgery)
  • Agile:敏捷开发(Agile Software Development)的缩写,是一种以迭代、循序渐进的方式进行软件开发的方法论

PM、RD、QA、OP 角色

  1. PM: Product Manager,产品经理,又称品牌经理。举凡产品从创意到上市,所有相关的研发、调研、生产、编预算、广告、促销活动等等,都由产品经理掌控。
  2. RD: Research and Development engineer,研发工程师,对某种不存在的事物进行系统的研究和开发并具有一定经验的专业工作者,或者对已经存在的事物进行改进以达到优化目的的专业工作者。
  3. QA: Quality Assurance,品质保证。QA的主要职责就是质量保证工作。
  4. OP: Operator,操作员,管理员。

技术owner

owner是临时授予的负责人,负责主导某个项目某个端(后端或者前端)的整体工作。

对内

  1. 关键模块技术分析、设计、开发;
  2. 切分开发任务且制定任务优先级和提测节奏;
  3. 关注组员开发进度,如果有出现不能按时开发联调的,要立刻帮忙处理;
  4. 解决开发过程中,组员提出的各种疑难杂症;

对外

  1. 保护模块内成员,尽量使得只有自己与外部(测试、大数据、pmo、产品)对接,让组员集中精力做业务开发;
  2. 跟踪开发联调进度;
  3. 关注【开发环境】的稳定性,随时介入解决;
  4. 关注整个模块bug数,日清bug;
  5. 辅助测试人员上线,且成功上线后,要关注上线的功能是否稳定;

OKR

OKR是目标管理工具,KPI是绩效管理工具。

  • OKR侧重过程管理,自我驱动。而KPI更多是围绕目标考核。
  • OKR是透明可视化的,人人可看见。同时OKR更多服务创新、挑战性目标,可以与KPI互补。
  • OKR突出团队合作,共同达成目标。KPI偏向考核个人贡献。

OKR的具体运用

  • OKR中的O是定性的,KR是完成OBJECTIVE的具体事件,需要符合SMART原则。
  • OKR中的O是透明的,但遇到具体商业保密性质的事件,也是可以进行脱敏,比如进行查看权限限制或者是数字脱敏
  • OKR中的KR是动态调整的,比如O发生了变化或者是客观环境导致了KR无法执行

整体每个员工的OKR,第一是支撑领导(拆解领导的O或者是认领上级的KR),第二是指引下属,第三是协助跨团队打通

整体OKR管理上,可以按照 达成共识(制定OKR)- 日常跟进(进度管理)- 整体复盘来进行。

降级 熔断 限流

出处:作者 yes的练级攻略 链接:https://juejin.cn/post/6844903838231576589

降级

降级也就是服务降级,当我们的服务器压力剧增为了保证核心功能的可用性 ,而选择性的降低一些功能的可用性,或者直接关闭该功能。这就是典型的丢车保帅了。 就比如贴吧类型的网站,当服务器吃不消的时候,可以选择把发帖功能关闭,注册功能关闭,改密码,改头像这些都关了,为了确保登录和浏览帖子这种核心的功能。

一般而言都会建立一个独立的降级系统,可以灵活且批量的配置服务器的降级功能。当然也有用代码自动降级的,例如接口超时降级、失败重试多次降级等。具体失败几次,超时设置多久,由你们的业务等其他因素决定。开个小会,定个值,扔线上去看看情况。根据情况再调优。

熔断

降级一般而言指的是我们自身的系统出现了故障而降级。而熔断一般是指依赖的外部接口出现故障的情况断绝和外部接口的关系。

例如你的A服务里面的一个功能依赖B服务,这时候B服务出问题了,返回的很慢。这种情况可能会因为这么一个功能而拖慢了A服务里面的所有功能,因此我们这时候就需要熔断!即当发现A要调用这B时就直接返回错误(或者返回其他默认值啊啥的),就不去请求B了。我这还是举了两个服务的调用,有些那真的是一环扣一环,出问题不熔断,那真的是会雪崩。

当然也有人认为熔断不就是降级的一种的,我觉得你非要说熔断也属于一种降级我也没法反驳,但是它们本质上的突出点和想表达的意思还是有一些不同的。

那什么时候熔断合适呢?也就是到达哪个阈值进行熔断,5分钟内50%的请求都超过1秒?还是啥?参考降级。

限流

上面说的两个算是请求过来我们都受理了,这个限流就更狠了,直接跟请求说对不起再见!也就是系统规定了多少承受能力,只允许这么些请求能过来,其他的请求就说再见了。

一般限制的指标有:请求总量或某段时间内请求总量

请求总量:比如秒杀的,秒杀100份产品,我就放5000名进来,超过的直接拒绝请求了。

某段时间内请求总量:比如规定了每秒请求的峰值是1W,这一秒内多的请求直接拒绝了。咱们下一秒再见。

UGC、PGC、OGC

参考文章

概念

  • UGC:User-Generated Content,用户生产内容,泛指以任何形式在网络上发表的由用户创作的文字、图片、音频、视频等内容,它的发布平台包括微博、博客、视频分享网站、维基、在线问答、SNS 等社会化媒体。
  • PGC:Professionally-generated Content,专业生产内容, 生产创作主体是由专业精英构成,其发展历程早于 UGC,生产程序偏向专业性,内容质量可控性更强,对生产者知识背景和专业资质的要求较高。
  • OGC:Occupationally-generated Content,即职业生产内容,指主要通过具有一定知识和专业背景的行业人士生产内容,并且这些人会领取相应的报酬(如部分新闻网站雇佣的内容编辑)

目前又出现了AIGC,顾名思义,AI所产出的内容

区别

UGC和PGC的区别是有无专业的学识、资质,PGC的生产创作主体在所共享内容的领域具有一定的知识背景和工作资历,UGC则没有。

PGC和OGC是否领取相应报酬作为分界。PGC的生产创作主体往往是出于“爱好”,义务的贡献内容,不收取报酬;而OGC是以职业为前提,其创作内容属于职务行为,获取报酬。

UGC和OGC没有交集。在一个平台(网站)上,用户和提供商总是相对的,既是该平台的用户也是该平台的提供商的角色可能有,但属于极少的群体。

PUGC

PUGC (Professional User Generated Content),即专业用户生产内容以UGC形式产出的相对接近PGC的专业内容。PUCC模式是UGC、PGC模式发展中逐渐演化出的一种全新生产模式,率先由国内数字音频领域提出,后延伸到视频内容生产领域,被认为是“互联网短视频长远发展的趋势”。PUGC短视频既满足了用户对专业化、高品质内容的需求,又达到了贴近性且个性化的效果,满足了短视频用户的多种需求,极大程度提升了短视频平台内容的品味。You Tube与B站目前是全球PUGC较为集中的社交型视内容网站,其中B站已经在内容战略上明确转向“建设PUGV( Professional User Generated Viden)社区”。

盲审

盲审是一种评审方式,就像考试时老师不知道你的名字一样。

在盲审过程中,评审者或审查者不知道作者或制作者的身份,只能根据作品本身的质量、内容和结构来做出评价或决定是否通过审查。这种方式可以保证评审或审查的公正性和客观性,通常用于学术、出版、电影等领域。

盲审有单盲和双盲两种形式,单盲是评审者不知道作者的身份,双盲是作者和评审者都不知道对方的身份。

 评论