分类目录归档:架构与远方

session

WEB 会话管理杂谈

1 前言

某一天,有同事在产品问题反馈大群里扔出一个问题:登录后隔两天再打开页面就需要重新登录。在查问题的过程中,我们有提到 7 天过期,老板对此也扔出了一个问题:为什么是 7 天。于是有了今天这篇文章。首先我们先看一下 WEB 会话管理的概念。

2 概念

在说 WEB 会话管理之前,我们需要先说一下 HTTP 协议。这里我们暂且不提 HTTP2.0 和 HTTP3.0,本文的 HTTP 协议主要是指现在使用最广泛,使用历史最久的 HTTP1.x 版本。

HTTP 协议是一个无连接无状态的协议。

  • 无连接是指限制每次连接只处理一个请求,服务端处理完客户端的请求,并收到客户端的应答后,即断开连接。后面协议中增加了 Keep-Alive,这个特性使得客户端到服务器端的连接持续有效,当出现对服务端的后继请求时,Keep-Alive 功能避免了建立或者重新建立连接。
  • 无状态是指在协议层面对于事务处理没有记忆能力,服务端不知道客户端是什么状态。当我们给服务器发送 HTTP 请求之后,服务端根据请求内容给我们返回数据,但是返回数据后,服务端不会记录任何信息。

在互联网早期,这样的协议完全能满足 WEB 应用的需要,但随着 WEB 应用复杂度的提升,识别用户是谁,记录用户的行为,有用户状态变成了刚性需求,或者说是核心功能点。 此时,会话管理应运而生,会话管理是一种控制和维持用户交互状态的机制,它定义了一系列用于管理用户和 WEB 应用系统交互状态的措施。

会话管理有两个关键点,一个是怎样存储,另一个是存储什么。

3 存储方式

3.1 服务端 session

在早期的有会话管理的 WEB 应用中,会话经常存储在服务端的 session 中,常见的 WEB 编程语言都自带 session 的处理逻辑,如 PHP 和 Java 都默认带有 session 的扩展或组件,如 PHP 中的全局变量 $_SESSION。客户端存储 sessionid,通过 cookie / 隐藏的表单字段 / 重写 URL 的方式传递 sessionid,后两种方式一般在禁用 cookie 的时候启用。

服务端 seesion 的优势

  • 安全性好,客户端与服务端保持会话状态的媒介始终只是一个 sessionid 串,我们一般会保证这个串的随机性,以防止攻击者遍历或穷举;除非通过 CSRF 或 HTTP 劫持等方式,才有可能冒充别人进行操作。最坏的情况就算是冒充成功,在服务端我们也会有一些登录凭证的验证来进行纵深的防御;
  • 可控度高,在服务端集中存储,后台同学可以对其进行操作,比如踢下线之类的操作。

针对服务端的存储方式,就会出现了我们在前言中提到的过期问题,为什么要有过期?

  1. 为了节省服务器资源,登录态相关信息存储在服务器还是需要一定资源的,如果一直不过期,几千万上亿的用户登录态数据将是较大的一个成本,而这个成本是完全可以省下来的;
  2. 为了安全,用户长时间未操作,如果有人用了他的账号干了点别的,这样就存在较大的风险;另外在业务逻辑上可以实现抢登等逻辑以规避一些安全上的风险。

有了过期,就会有过期时间,常见的过期时间有 1 小时( 3600 秒),2 小时( 7200 秒),1 天, 7 天(一周),15 天,30 天(一个月)。这个过期时间更多的是经验值,或者说是一个大家认为合适的值。这个值对业务的影响,貌似没有一个客观的评价。

服务端的 seesion 的常见存储方案如下:

  • 单机方案,存储要么是硬盘,要么是内存,二者的区别在于获取和写入的速度,对于海量的互联网应用来说,存储到内存方案更常见一些。单机存储方案是有一定上限的,其上限是单机存储的上限。
  • 分布式方案,分布式的内存数据库如 Redis / Memecached,Tomcat 等都有现成的共享 session 方案。分布式存储方案从理论上来讲是没有存储上限的,可以给 Redis 做分布式部署。

考虑到服务器的负担和架构的复杂性,依赖于浏览器每次请求都会带上 cookie 的特性,我们可以把用户的登录凭证直接存到客户端(浏览器)中。当用户登录成功之后,把登录凭证写到 cookie 里面,并给 cookie 设置有效期,后续请求直接验证存有登录凭证的 cookie 是否存在以及凭证是否有效,即可判断用户的登录状态。当年 Rails 的默认会话存储方案是用 cookie 方案。

优点

  • 实现了服务端的无状态化,彻底移除了服务端对会话管理的逻辑,服务端只负责创建和验证登录 cookie 即可;
  • 不同应用间的登录态可以通过算法或密钥的一致性来保持,以实现会话共享。

缺点

  • cookie 有大小限制,存储不了太多数据,同时会话会占用其它业务场景的空间,从而导致 cookie 空间紧张;
  • cookie 在每次请求时都会带上,当会话中有较多的冗余数据时,会对性能有一些影响,并且产生一些不必要的网络带宽;
  • 多应用时可能会有跨域问题,浏览器在发起请求时会检查所有存储的 cookie ,如果某个 cookie 所声明的作用范围大于等于将要请求的资源所在的位置,则会把该 cookie 附在请求资源的 HTTP 请求头上发送给服务器。当作用范围小了,或者交错了,则会出现跨域问题。

3.3 令牌方案

相对于前面两种方案,令牌方案是前后端分离后的常见方案,session 的概念在这个方案里面更淡一些。

在讲令牌方案之前我们先讲一下安全上两个非常重要的点:认证和授权。有时候会把这两个东西弄混,其定义如下:

  • 认证是这样一种验证过程:通过让用户、网站、应用程序通过提供合法证书或验证方式,以证明他们符合自己所宣称的身份。
  • 授权是指的是一个验证某用户能访问什么的过程。在授权过程中,某用户 / 应用程序的权限级别被确定后,才被允许访问特定的 APIs / 模块。通常,授权发生在用户身份被认证之后。
区别 认证 授权
作用 确定用户所宣称的身份 确定用户可访问的权限
方式 通过合法凭证校验用户 通过规则和策略校验访问
时机 早于授权 在认证成功后执行
实现 通过 ID tokens 实现 用 Access Tokens 实现

基于令牌的认证和授权是现在最流行的的一种技术,当用户在某处输入一次其用户名和密码后,作为交换会得到一个唯一生成的已加密令牌。该令牌随后会替代登陆凭证,用以访问受保护的页面或资源。当我们要进行下一步的业务操作,会通过令牌获取到用户的的信息和会话的信息,此时一般是通过进程内的缓存或者某个特定的微服务来获取,这些微服务的后端的存储因公司技术架构和服务而异。一般来说,对于海量的互联网应用来说,这里最终还是从内存中获取的数据,如前面说到的分布式 NoSQL 数据库。

一个令牌就是服务器生成的一段数据,包含了唯一性识别一个用户的信息,一般被生成为一长串随机字符和数字。

比如看起来可能像这样:bb74324734bcf34748bb08bu2842f3288 或更复杂些比如: eyJ0eXAiOiJqd3QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ1bXMiLCJzdWIiOjY1NDA1NjI5NCwiYXVkIjoiZ2FvZGluZ3giLCJleHAiOjE2NDE5MDgzOTZ9.8MZaB55vlScSDZxBmO-N9ol9UTvYPVvgUFab7dFe6fY 这个令牌本身是无意义和无用的,但结合适当的令牌系统,就会变成保证应用安全性的重要一环。

基于令牌的实现过程一般如下:

  1. 用户通过用户名和密码(或者其它登录方式,如国内的微信扫码)请求访问;
  2. 应用验证登录凭证;
  3. 应用向客户端发放已签名的令牌;
  4. 客户端存储令牌,并将其附加在其后的每次请求中一同发送(一般是带在 cookie 中,和 sessionid 类似);
  5. 服务器验证令牌并响应数据。

我们常用的基于令牌的方案有两个:

关于这两个方案的更详细的说明见:深入 OAuth2.0 和 JWT

在令牌的生命周期中存在两个较大的安全薄弱环节:

  1. 会话令牌生成过程中的薄弱环节,令牌的生成依赖于用户通过用户名/邮箱或密码生成,这里存在较大的泄漏风险;
  2. 所有处理会话令牌的薄弱环节,如传输过程中(没有加密的链路或被劫持等),日志记录中等。

4 存储内容

会话从本质上来讲是一种缓存,一种强关联用户的缓存,所以与用户相关的一些常用数据可以放在会话里面,如头像、用户名、真实姓名、积分等等。这些缓存数据都只读,当要更新时还是需要从数据库中获取后再次更新写入,而不是依赖于会话的数据。

除了常用数据我们经常还会把购物车或者菜单、权限等写入会话中,此时除了用户属性,还带上了业务属性,我们可以称之为业务会话。业务会话一般是指某个业务场景中需要临时缓存起来的数据,而且这部分数据大多数是要落库的,当用户会话过期重新登录后这部分数据还是要从数据库重新获取,加载到会话中。

5 小结

最后这个问题的原因是业务逻辑里面针对不同的渠道有抢登的业务逻辑,而这个逻辑在某个时候是不需要触发的。 此外,老板最后在群里问了一个触及灵魂的问题:

我们做一件事情的时候是依着惯性做事,还是基于深度思考后的决策?

自我反省中~~

这篇文章墨迹了几周,一直不知道如何写好,总觉得写得有点不如人意,如果往协议本身来写,好像也没有想写的,就这样吧。

6 参考资料

  • https://juejin.cn/post/6844904000811171847
  • https://www.cnblogs.com/lyzg/p/6067766.HTML
  • https://blog.csdn.net/tennysonsky/article/details/44562435

除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现,技术管理等相关话题,紧跟业界主流步伐。

qrcode_for_gh_5d3f534e15fe_344 (1)

security_logo

创业中的应用安全体系

1. 源起

在创业进程中,可能最开始我们会想着快速上线,一些性能、可用性或安全的问题是有时间就搞搞,没时间就放着;或者对于用户的一些异常行为,一些薅羊毛的行为没有特别的关注;又或者对于用户上传的个人资产没有做特别安全的隔离或保护等等。虽然现在看起来都没有引发大的问题,但是这些都是应用安全隐患,都是隐藏的雷,一旦被公众引爆,将惊天动地。

从更大的层面看应用安全,根据咨询公司 Gartner 统计数据显示,超过 75% 的安全攻击发生在代码应用层面。

Forrester 2020 年发布的调查报告 《 Forrester Analytics Global Business Technographics Security Survey,2020》中显示,在 480 家全球企业已经确认的外部攻击中, Web 应用程序和利用丢失/被盗资产,软件漏洞分别位于第1,2,4名,占比达到了 39%、35% 和 30%,其中软件漏洞主要指对于安全漏洞的利用攻击,攻击 Web 应用程序主要指基于程序的 SQL 注入、跨站脚本攻击、远程文件包含等。具体如图 1 所示:

从上图来看,应用安全,资源保护是目前我们安全防护的最佳切入点。

应用安全是应用级别的安全措施,旨在保护应用内的数据或代码免遭窃取和劫持。它涵盖了在应用开发、设计、测试、部署,上线后运营期间等发生的安全注意事项,及相对应的保护系统和方法。我们主要解决应用层和数据层的问题,网络层,物理层的问题不在本文的讨论范围之内。

从创业过程来看,我们有哪些数据泄漏的问题,我们有哪些敏感信息很容易被人看到,我们运营活动上线后有没有被薅羊毛,我们的用户里面有多少是机器注册的,我们的系统存在多少应用级漏洞,黑产是不是可以无门槛或门槛很低的获取到我们的数据或资源,我们的新业务上线时有没有东西能保证其是安全靠谱的,我们有没有办法及时发现这些问题并解决这些问题,从流程,机制,工具,系统各个层面,这就是我们这里所说的应用安全体系。

1.1 是什么

  • 是在部署常用防御工具和手段(比如防火墙、WAF 和 IDS 等)的基础上我们能做的流程、机制,工具、系统;
  • 是要在应用层面,去解决我们工作中经常会碰到的安全问题;
  • 是我们有意识的,主动的发现应用中的安全问题,发现用户的行为异常,业务异常,并给予解决。

1.2 不是什么

  • 不是公司的安全防御体系;
  • 不解决非技术安全相关问题;
  • 不解决所有的安全问题;
  • 不解决安全合规的问题;
  • 不解决超大规模类 DDoS 攻击的资源性攻击。

2. 安全问题梳理

这里我们从外部安全和内部安全来看可能面对的安全问题,外部是指对外的服务,内部是指企业内部的管理和控制,这里通过一些问题来反思现状。

外部安全
后台安全
    存储安全
        系统备份和恢复
            如果现在数据库被人删了,怎么办?如何快速恢复?
            如果现在代码全部被人删了或者 github 的账号完全不可用了,怎么办?如何快速恢复?
            如果现在阿里云的账号被封了,怎么办?如果有备用的账号,如何快速切换?
        配置存储
            如果配置中心挂了,有没有办法快速恢复?
            账号密码安全如何防护,代码配置中有吗?现在线上环境 apollo 的权限控制如何?
        MQ安全
            是否有必要的业务隔离?
            如果突破内网,是否有一定的鉴权逻辑?
    服务安全
        对外服务
            身份鉴权/访问控制
                用户资源安全(资产保护)
                    用户资源是否有访问鉴权?
                    用户资源或资产是否存在越权访问的情况?
            安全审计
                对用户的登录、注册和交易日志的审计
                对系统资源的异常使用的审计
                对重要系统功能的执行等的审计
                对其它重要用户行为的审计
            通信保密性
                传输通道加密
                内容加密
                传输加密(密钥是否存在漏洞的可能?)
            抗抵赖
                日志保留 6 个月
                操作详细流水日志
            容量安全
                各服务的 QPS 上限,容量评估
                资源消耗类服务的容量安全,是否存在很容易的攻击行为,如一些上传文件后的解析或者 AI 识别之类的
                MQ / DB 等是否有业务隔离和容量
            容错
                出错信息保护
                部分出错降级
        对内服务
            身份鉴权/访问控制
                服务间/接口访问控制
                服务间鉴权
                调用方身份识别
            抗抵赖
                详细调用日志
            应用生命周期的管理和隔离
            数据(包括用户数据)的管理和隔离
        安全框架
    资源安全
        商业化资源业务风控
        用户账号风控
        活动地址,接口地址,兑换码防穷举遍历
        在活动流程和规则上提高薅羊毛的门槛,形成规范
    数据安全
        数据量级泄漏
        业务数据泄漏
        敏感数据泄露
        防拖库、撞库
前台安全
    应用安全
        代码混淆
        应用加固
        安全密码控件
        敏感资料保护
        防代理
        常见 Web 攻击
            SQL 注入
            CSRF
            XSS
            爬虫
    接口安全
        SSL 加密传输
        参数加密
        防恶意调用,频控,降级
    账户安全
        身份验证
        登录验证码
        超时控制
        单点登录
        防信息泄漏 内部安全
管理后台安全
    严格且精细的权限控制
    商业化资源需要有审核流程,更细的权限控制,只能看到自己创建或者自己有权限的
    敏感信息(用户/订单/商业化)需要有针对敏感信息查阅的追溯手段和管控措施(是否考虑形成日报上报)
    对于钱相关的资源需要有监控和视图
代码和部署安全
    核心代码是否有专人管控
    上线的代码是否有必要的审核或 Review
    是否配置如同代码一样管控
    CI / CD 系统是否有必要的权限控制和安全管控
    CI / CD 流程是否实现自动化
    CI / CD 流程是否有必要的安全保护策略,如签名和密钥

如图 2 所示:

3. 如何建立应用安全体系

业界应用安全体系的建立有两主流方法论:一个是 SDL,另一个是 DevSecOps。

3.1 SDL 简介

SDL 是由微软最早提出的概念,安全开发流程(Security Development Lifecycle),在需求分析、设计、开发、发布所有阶段都引入安全和隐私原则,帮助解决软件安全问题,重点在于开发阶段,而安全培训是 SDL 最核心的概念。

SDL 大概流程如图 3 所示:

3.2 DevSecOps 简介

DevSecOps 是”开发、安全和运营”的缩写。它是一种文化取向、自动化方法和平台设计方法,将安全性作为整个 IT 生命周期的共同责任。 DevSecOps 的出现是为了改变和优化之前安全工作的一些现状,比如安全测试的孤立性、滞后性、随机性、覆盖性、变更一致性等问题;通过固化流程、加强不同人员协作,通过工具、技术手段将可以自动化、重复性的安全工作融入到研发体系内,让安全属性嵌入到整条流水线。

DevSecOps 是应用安全 (AppSec) 领域一个相对较新的术语,通过在 DevOps 活动中扩大开发和运营团队之间的紧密协作,将安全团队也包括进来,从而在软件开发生命周期的早期引入安全。这就要求改变开发、安全、测试、运营等核心职能团队的文化、流程和工具。基本上,DevSecOps 意味着安全成为共同的责任,而参与 SDL 的每个人都有责任在 DevOps CI/CD 工作流中构建安全。把安全融入到敏捷流程中,使得敏捷性与安全性并重。

DevSecOps 在软件开发生命周期更早期切入安全相关内容,就能更容易的收敛安全问题,让安全问题的解决成本更低,暴露在线上的完全问题更少。

DevSecOps 的过程有三个关键要素:

  • 授权(empowerment)
  • 赋能(enablement)
  • 教育(education)

授权或者放权,将控制权下放给团队,团队在理性分析的前提下,做出独立决定而不用害怕失败或影响。这里的团队成员不仅仅有开发,还有商务,产品,安全,QA 等等,所有项目成员都是奔着同一个目标:打造自己的产品。

赋能是指正确的使用掌握在团队手中的工具和资源,使其具体可操作性,如打造一种注重自动化、通过工具来解决重复任务,并尽可能减少以后的操作并增强安全性的理念。赋能不仅仅是提供知识和工具,而是让这种知识和工具能够通过多种渠道和媒介可快速获取且好用,以便它可以被团队或是个人以他喜欢的方式去使用和分享。

教育,在团队中建立安全文化,通过分享和培训让所有的成员都具备安全意识和技能是整个过程中最重要的点。

最终 DevSecOps 落地时,对整个研发团队的要求是这样的:

  • 安全测试由研发团队完成;
  • 测试期间发现的问题由研发团队管理;
  • 线上安全问题由研发团队负责处理;
  • 解决安全问题的责任在于研发团队。

3.3 选择适合自己的

SDL 相对于 DevSecOps 更偏于传统,如果要严格执行起来,其存在流程重、人员要求重等问题,一般是需要有专职的安全团队来执行。 但是要想直接达到 DevSecOps 的理想状态对于一个新创业的团队来说也是不现实的。

对于一个创业公司,可能需要更敏捷一些的方式,让敏捷性和安全性并重,所以我们更倾向于在 SDL 的基础上,融入部分 DevSecOps 的手段。

3.3.1 核心理念

  • 研发团队对安全负责,一切安全问题都是研发团队的问题,专门的安全团队只提供技术支持和技术培训(可以适当花钱请第三方专业机构),规避安全信息共享壁垒和在有专职开发团队时,开发绕过安全监管等情况;
  • 研发流程中全链条增加安全环节,安全不再是流程外的冗余流程,安全可以做轻,但是必须要有,特别是核心的逻辑,将安全前置;
  • 专职的安全团队从实战的角度,以攻击者的角度来发现问题,反馈给研发团队自己解决(提供标准解决方案),反向考核整个研发团队的安全绩效;
  • 建立高效的 SRC。

3.3.2 SDL 通用版

安全培训
| 安全概念、威胁评估、WEB 安全、安全测试及隐私保护
    提高全体项目人员的安全意识
    进行安全培训
需求分析
| 建立安全标准;创建安全指标;风险点评估
    确定安全需求标准,制定安全需求表,供后续开发检测
设计阶段
| 建立设计方案标准;提出安全方案;风险评估建模
    建立技术方案安全标准
    对不同的业务形态提出不同的安全方案
    建立风险评估模型
开发阶段
| 使用安全的工具、弃用不安全的函数或方法;静态扫描
    使用安全的工具:包括开发团队使用的编译器,框架,组件等
    弃用不安全的函数或方法
    | 安全规范编写代码,并在开发过程中对代码进行 Review
    静态分析
    | 对代码进行安全脆弱性分析和渗透性测试
测试阶段
| 动态安全扫描;模糊测试;评估安全方案
    动态分析(其实就是黑箱测试)- QA
    模糊测试
    | 故意向应用程序引入随机不良数据及格式,诱发程序产生故障。模糊测试的基础是必须了解熟悉程序的功能状态、设计规范等
    代码审计 - SRE
    | 代码安全扫描,开发过程中,开发人员每次更新代码都要进行扫描,并有权限查看相关项目漏洞情况,进行整改(不允许有中高危以上漏洞)。开发有权对漏洞进行忽略处理,但需要承担相应后果。若不知道如何处理,可请安全组提供解决方案。
    WEB 应用扫描 - QA
    人工渗透扫描 - 第三方专业安全团队
部署阶段
| 应急响应计划或预案;安全流程确认;发布归档
    明确安全应急响应计划
    构建发布流程工具卡点 AST 工具集
        静态应用安全测试 (SAST)
        软件组件分析 (SCA)
        交互式应用安全测试 (IAST)
        动态分析测试 (DAST)
    发布归档
线上阶段
| 执行线上应急响应流程
    第三方专业安全团队发现问题
    安全问题等级制度
    安全问题响应流程

脑图如图 5 所示:

3.3.3 我们现在可以做什么

在项目早期进行如下的投入是合适的,并且只需要开发同学的增量工作来保持良好的测试覆盖率和持续的构建

  • 单元测试和集成测试的覆盖范围要足够全面,以确保生产版本的缺陷风险低到可接受的程度,而不需要主要依赖人工进行的质检工作;
  • 本身安全可靠的 CI/CD 流水线;
  • 经常使用的、可靠的基础设施,可用于分开部署生产环境的回滚;
  • 允许代码和配置分开交付的软件架构,如配置中心。

应用安全是一个系统化的,长期的工程,对于现在的我们来说,不可能一次全链条都上,也不可能一次性的把大家的安全意识提到理想的水平。如何在保障业务快速发展的前提下,兼顾安全防护是当下我们需要考量的问题。

参照 SDL 通用版,建立较好的流程规范,安全问题等级制度和响应流程。有必要的话请第三方安全团队作为专职安全团队,定期对公司内外部做安全扫描,参照安全问题等级制度和响应流程,处理线上的问题,并且反向考核现有公司内部研发团队的安全绩效。同时研发团队在流程和意识上逐步增加安全卡点,提升开发过程中的安全质量,通过一些初步的安全工具链,快速自动识别安全问题。

4. 结语

以上纯属个人对现有应用安全的理解,供大家参考,有错误或不明确的地方欢迎指正,有更好的更完善的方法,欢迎评论探讨。

最近在看一本书,里面有一句守夜人的誓言:“若暗夜终临,吾必立于万万人之前,横刀向渊,血染天穹”,而安全于业务就是那个立于万万人之前的我们。

5. 参考资料

  • https://zhuanlan.zhihu.com/p/146149814
  • https://zhuanlan.zhihu.com/p/73675141
  • https://www.jianshu.com/p/ba886a6a28d8
  • https://cloud.tencent.com/developer/article/1587312
  • https://www.whitesourcesoftware.com/wp-content/media/2021/04/forrester-report-the-state-of-application-security-2021.pdf

 

除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现,技术管理等相关话题,紧跟业界主流步伐。

qrcode_for_gh_5d3f534e15fe_344 (1)

landing_head

高阶技术管理岗空降落地实践指南

在互联网企业中,技术同学从大厂高 P 出来,空降到中小型的创业公司做技术管理的情况常有发生,这对于高 P 同学来说是一个较大的转变,会有一个适应期,有些比较顺利的渡过了这个适应期,也有些可能水土不服,甚至回流到大厂的情况。那么,作为一个高阶技术管理岗应该如何空降落地呢?如何在落地过程中保持平和的心态?如何快速上手业务,搞定事情?基于这些问题,我们有了这个落地实践指南。

高阶技术管理空降落地的关键点我觉得主要是两个大的方面,一个是心态,一个是节奏。

1. 心态

中国古代有一个”心态过门尤当先“的寓言笑话:

  洞房花烛夜,羞羞答答的新娘低头看着地上,忽然掩口而笑,指着地上对新郎说:“看,看,看老鼠在吃你家大米。”

  第二天,新娘早早起床洗漱,看到老鼠又在吃大米,大声怒喝:“该死的老鼠,竟敢偷吃我家大米!”

  接着是“嗖”的一声,一只鞋飞了过去。

  新郎听了大喜,知道新娘的心已经离开原来的娘家,过门到现在的这个家了。

  过了门儿啦,新娘心态的转变从她对待老鼠的态度上就可见一斑,所以说,“心态过门尤当先”。

这个笑话对于我们新加入一个公司同样适用,心态很大程度上决定了是否能适应这个新的公司。 心态可分为 4 个点

1.1 对过往的态度:保持敬畏

在大厂工作多年,已经熟悉了大厂的流程和做事方式,习惯了有完善的制度和流程,习惯了强力的支撑系统。到新的公司,可能会觉得这里不行,那里也不好,甚至觉得自己是过来拯救团队的,是救世主。一上来就高谈阔论,方法论,高可用高性能等等,或者直接全部推翻重来,甚至会有直接换一个技术栈,这样操作往往会闹笑话,出问题,这里背后的原因是在于心态。有些急了,有些不切实际。

高 P 技术同学新入职一家新的公司,负责某块的技术,首先要有谦卑的心态。谦卑,就是对万事万物怀一颗敬畏之心,持一份包容情怀,谦卑的人更懂得尊重别人。

新的公司肯定是存在一些问题才会请你过来,所以有问题是一件很正常的事情,但是我们来了后,要保持谦卑,对原来的架构保持一颗敬畏之心,一个公司发展到这个规模,经历了非常多的风风雨雨,还能存活到现在肯定是有其道理的,而且还有一些从表面上看不到的问题,如冰山一样,深埋在水下,保持敬畏,尊重历史成绩。

1.2 快速融入的秘诀:不着急,不害怕,不要脸

“不着急,不害怕,不要脸”是冯唐在《冯唐成事心法》中常提的九字真言,对时间不着急,对结果不害怕,对别人的评价不要脸。

到新的公司,每一个新同学都会想想快速融入,想快点搞清楚公司的做事逻辑、业务流程,技术实现,想快点出成绩,想快点……

这些都是正常的,不要着急,给自己一些时间,给周围的同学一些时间,给事情的发生和发展足够的时间,遵从事物发展的客观规律,尽心尽力,有定力和耐心,在理解公司战略的基础上,沉下去把业务做起来,不用害怕,一切都会是最好的安排。

不要脸,是指快速融入现有团队不要脸,多听听大家的意见,为大家争取一些小的利益,和大家一起吃饭,一起加班,一起讨论问题,有空出去多聚餐,喝点酒,喝多了才好称兄道弟。

同时,放下过去的种种,不管你在过去是什么岗位,带多大的团队,不管是 CTO 还是技术总监,这都是过去的平台给你的,都已经是过去式,在新的地方你就是一个萌新,最多算一个工作很多年的老萌新,作为一个萌新就是要多看,多问,多想,不要脸的那种。

多看看公司的文档,虽然文档刚开始不那么全,但是只字片纸也能让我们对业务有更多的了解;多看看同事的做事方式和流程,知道在这样一个新团队里面大家的工作方式和节奏,发现好的地方和不好的地方,先记下来;多问问公司呆的久的人,有问题的时候多问问业务线的负责人,寻根究底的把项目搞清楚;多想想一个项目或一个团队是放在那里,多想想一个人为什么会出现在某个项目,多想想自己是来做什么的,多想想自己能带来什么价值。

在融入的过程中,不要怕丢脸,敢于被打脸,你问问题的人可能年龄比你小,工作年限比你少或者各方面都不如你,但是在这项目就是比你熟悉;或者一个完全陌生的人,很慢才回你的问题,甚至不回,这些都不重要,关键点是能得到你要的信息,能够帮助你更多的了解公司或项目。在公司的会议上敢于发表自己的意见,可能是错的,可能会被打脸,这些都不重要,关键点是能让更多的人认识你,更快速的融入新的公司。

如此,不着急,不害怕,不要脸,快速融入。

1.3 应有的工作态度:尽心

是尽心,而不是尽力,因为尽心和尽力是两回事。尽心做事和尽力做事,有天壤之别。

其差别关键点在于投入度,如果有人问有没有把握把事情做好,回答是尽力而为,这个回答没有错,也显得很敬业,但是其潜台词通常是“我的能力只有这么多,所以就只能做这么多”,但是每个人的潜力都是很大的,个人的力量可以释放得更充分一些。

如果是尽力,其潜台词是“我一定能完成任务,而且能做得更好、更多”。尽力有些给自我设限,只对自己的能力负责,缺少一些进取之心,只有尽心才能释放潜能。在选择团队成员的时候,一个尽心的员工,哪怕能力差一些,技术差一些,进展慢一些,但是投入度高,能全心全意的投入来完成工作,非常积极,假以时日,能力,技术、进度都将不会是问题。假设一个人的能力值是 1 ,一个尽力的人最多只愿意发挥 1 的能力值,甚至 0.8 ,而对于一个尽心的人来说,哪怕自己的能力值没有 1 ,其也会想办法达到 1 ,甚至超过。不给自己设限,释放自己的潜能。

尽心能带来安全感。尽心做事的时候会有特别重的 Owner 感,有那种这个事情就是我的,和其它东西无关,纯粹是想把这个事情做好;我的心血,我做的东西都在上面,就有了极强的安全感。 这里还有一个前置逻辑,就是信任,组织对个人的信任,组织认为这是你的事情。

1.4 能成事的做事方式:躬身入局

罗胖在 2019 年的跨年演讲中提到了一个概念–躬身入局,是曾国藩讲的一个故事,让人印象至深。 故事是这样的:

  两个农人,挑着沉重的担子,相遇在农田间狭窄的田埂上。
  他们谁也不愿意相让,因为那样的话,想让的那人就要一脚踩到泥泞的水田里,沾一脚泥。他们就那样顶上了,谁也不让谁。

  作为一个旁观者的你该如何相劝呢?
  我们能想到的是:退让一步,海阔天空,要不都走不了。
  其实大多数人,有时候脑子里想的就是:“我凭什么要让你?大不了都不走,看谁犟得过谁!”

  曾老先生从另一个角度提出了解决问题的方法——做一个躬身入局的人:
  旁观者跳入水田,接过其中一个人的担子,让他先过。这样,问题就解决啦。

  这也就是曾老先生所说的:”所谓天下事,在局外呐喊议论总是无益,必须躬身入局,挺膺负责,方有成事之可翼。“

何为做事之人?

不是置身事外,指点江山。而是躬身入局,把自己放进去,把自己变成解决问题的那个人。

躬身入局是对一个管理者基本的要求,是对其执行力的要求。真正的执行力是深入业务场景,和产品,运营、开发小伙伴在一起,共同解决问题、共同克服困难、共同面对挑战、共同承担责任。败则拼死相救、胜则举杯同庆。时时刻刻思考“自己在团队发展过程中扮演什么角色”这个核心问题,以及如何把深度思考后的结论付诸行动,持续迭代。

清晰了心态,我们再聊一下入局的节奏。

2. 入局节奏

人生犹如棋局,职场更甚。能识局者生,善破局者存,掌全局者赢。

2.1. 识局

  1. 了解行业大背景,公司所在的赛道是什么?如果是创业公司,投资人是否关注这个赛道?主要营收靠什么?竞争对手有些?竞争对手的生存情况如何?这个步骤应该是面试这家公司之前就做了一些,本次就是细化其中的更多的关键数据,为后续的一些判断和决策提供顶层的支撑。
  2. 了解公司大背景:公司的文化是什么?大家是如何协同工作的?时间管理是怎样的?做事的价值观是怎样的?怎样的人在公司会更能得到大家的认同?
  3. 了解所在位置: 所负责的业务在公司的位置在哪?所负责的团队在公司的位置在哪?对接的部门,合作的人是哪些?有哪些诉求?业务边界在哪里?利益的边界在哪里?公司大的项目有哪些,干系人有哪些?项目历史情况,现在的情况如何等等;
  4. 了解团队成员:逐一和团队成员做一次 1v1,了解其背景,从 HR 处拿到入职时间 / 工作年限 / 级别 / 薪资结构等信息,了解人才梯队
  5. 了解现在的问题有哪些?挑战点有哪些,是人的问题,流程的问题,还是历史的问题等等,了解清楚公司招我过来是希望我解决什么问题的。

2.2. 破局

2.2.1 先小后大,以点破面

新官上任不用着急,先梳理业务逻辑,人才梯队,业务流程等等,找到问题点,找到破局点。

不要图大而全,不要一上来就搞大系统,先做小,从小点突破,拿到业绩和成果,建立信任,然后再做大的规划。 大的规划从规划到落地需要的时间太长,这样一个很长的时间里面如果没有产出,没有看到有成效的内容出现,可能还没有等到开始落地就已经出局了。 做小点是为了解决生存问题,做大的规划是为了解决发展的问题,顺序不能搞反了。

常见技术破局点:某些服务的性能问题,频发的告警服务,高负载的数据库,客诉问题多的点,新项目的技术架构方案,研发流程中的卡点,构建发布流程的优化,长期没有人能解决的问题、痛点或难点并且能快速解决的。

2.2.2 搭班子,带队伍

除了专注于破局的点和事项以外,尽快搞定人的问题,把团队搭起来,把人才梯队搭建好,管理者更多的是通过一线同学的手来拿结果,没有一个合格的团队,破局难,掌局更难。

首先,做好现有团队的沟通工作,不要让人觉得你是来抢事的,要让他们相信你是来帮忙的,来帮大家解决问题的,空降后和团队在行政上是上下级关系,但是根本上是合作的关系,来的作用是帮忙大家的。带领大家一起赢,遇到问题,是跟我上,而不是给我上。

其次,尽量用现有团队成员,也可适当新招或带一些人过去。现有团队有其优点,也会有其缺点,这些人在公司的时间长,掌握的信息量和资源都是一个新人缺失的,甚至有的人是跟了老板多年的老员工,能在老板面前说上话,甚至可能老板会问新来的这家伙感觉怎么样。在刚到团队的时候,要团结这些原有团队的人,有助于快速掌握资源和信息,加速你融入和破局的过程。

最后,在团队中找到志同道合的人,作为核心成员培养他们,让他们成为你的得力助手。饼还是要画的,落到手的实际也是需要有的,大棒和枣一个都不能少。

如果现有团队里面有不服你的人,极度不配合,但是还是要想办法去融入,不要脸的那种,等站稳后再看怎么处理。比如有一个 leader 不服,到处鼓动大家不配合工作,没关系,继续安排工作,只要工作能完成得好就行,而且还给比较好的绩效,针对好的绩效再提出高的标准,如果没有达到标准再降绩效,同时,招聘或内部提拔一个可以替代的同学,半年或者一年以后,站稳了后再视情况考虑后续的操作。

凡事都有套路,还是套路得人心,常用管理套路:

沟通反馈:1v1、个人目标制定、OKR、反馈、周报、周会、月会、团队建设、非正式沟通、向上管理
项目管理:项目进度、风险管理、紧急需求、复盘、跟进、反馈、拿结果
项目质量:线上稳定性、代码质量、Code Review、交付质量
人员管理:备份、淘汰、晋升、激励、绩效管理,360
人员招聘:业务盘点、人才盘点、人才素质模型、人才梯队、实习、试用
学习:总结、分享、交流、达摩院

2.2.3 破局

在和团队充分沟通,了解一些业务,了解业务中的痛点后,根据难易程度和优先级,选择个人觉得有挑战,好突破的点,找到破局点后,和领导沟通,得到充分的支持和授权,拉兄弟们一起干,和团队一起拿结果,在这些小点的累积中,上级对你的信任、团队对你的信任慢慢就建立起来了,如此,在这个新环境算是存活下来了,至此,已破局。

2.3 掌局

破局以后,随着时间的增加,从一个新人慢慢变成老人,对业务越来越熟悉,对人也越来越熟悉,此时不能飘,得躬身入局,把自己放进去,把自己变成那个解决问题,能掌控全局的人。

掌控全局可以从人员管理、团队演进和流程机制三个方面来掌控。

2.3.1 人员管理

人员管理主要是人的聘用育留。

  • 招人:招人得先有业务,研发是为业务服务的,先搞清楚业务是要做啥,然后才是盘人,看看现在有什么人,都有什么样的人,还需要什么样的人,这样的人在哪里可以找到,以及给这些人我们可以提供什么样的待遇,什么样的机会等等;常用套路:业务盘点,人才盘点,人才画像,人才素质模型,人才地图,面试流程,面试官标准,人才策略,内推,专场,
  • 用人:一线执行的同学看才能,对于技术同学来说就是技术水平怎么样,另外,还会看态度,或者说是工作的投入度,对于投入度高的同学会有一些资源倾斜;中层看德行和才能,这里的中层是指有管理职能的同学,同样也需要看技术能力,同时要看规划的能力,项目管理能力,沟通能力等等;高层看格局,是不是能从让公司更好出发来解决问题,而不是局限于自己的一亩三分地;常用套路:聚集,复盘,人才梯队,人才密度,分层用人,360度考核,加减分制,模块负责人,需求负责人,项目管理,风险管理,老人做新业务,新人做老业务
  • 育人:这块主要是培训分享,新人融入,以老带新,员工成长,常用套路:IDP,导师制,分享会,管理培训,技术通道,自我迭代,培训体系,职级体系,文化,价值观,方法论,系统化
  • 留人:基层基本上是看待遇,这里的待遇除了薪水,还看一些软性的福利和团队氛围,说白了就是看呆得爽不爽,有没有成就感,有没有感受到成长;中层靠情感,主要是领导是不是靠谱的领导,能不能帮助他提升,是不是一起奋斗过,对团队有感情了就不那么容易走;高层就要看事业了,主要是看这个事情是不是能做得大,大家在一起最后会不会把这个蛋糕做得更大,能让自己有那种事业的成就感,并且在事业中能得到较大的回报。

2.3.2 团队演进和价值观

对于一个团队来说,一般分为三个级别,初级,中级,高级,但是这三个级别并不是泾渭分明的,可能会三个级别的东西会同时存在,因为团队中包含的内容模块较多,不同的内容模块所在的级别不一样。

  • 初级团队:初级团队靠骨干,以人治为主,这个阶段把核心骨干找到或者培养起来,让他们来搞定事情;
  • 中级团队:中级团队靠规范,以人治 + 流程规范为主,在核心骨干的基础上,把好的经验以流程规范的方式沉淀下来,就算是核心骨干走了,还有东西可以传承;
  • 高级团队:高级团队靠系统,把好的规范做成系统,用系统来驱动团队的进步,在系统的支撑下,让好的东西传承下来,让大家更高效更好的工作。

三个层面团队不是一蹴而就的,也没有清晰的分层,是一个演化的过程,从培养骨干开始,到规范化,到系统化落地,一点点积累,这样整个团队就会变得更好一些。这也是带研发团队最大的挑战。

在清晰了解团队所在阶段的同时,团队领导者需要从平时的工作中提炼出适合自己团队的价值观。

价值观是什么?

团队的价值观就是表达一个团队赞同什么,反对什么,是一个团队做事的行为准则。 价值观会潜移默化地体现在团队成员的做事的态度和方式方法上。

如我们的价值观是:

  • 允许犯错,但不容忍罔顾教训、一错再错 这个是《原则》这本书里面提到一个观点,也是我们非常认可的一个观点,允许犯错是让大家不要畏惧挑战,敢于试错,不容忍罔顾教训是我们遇到问题和错误要复盘和总结,找到问题的根本原因,总结出方法论,后续可以规避类似的错误。
  • 长期有耐心,基于深度思考的持续迭代 长期有耐心是一本讲美团的书里讲的内容,对于我们同样适用,持续迭代,长期有耐心的把业务做好,提升自己,自我迭代。

2.3.3 机制和系统化建设

带研发团队,在流程机制方面主要是关注研发效率和研发质量。对于研发效率和质量需要有一个完整的研发流程来保证,一般的流程如下:

流程保障之外,还需要和产品,UI 等各方确认协同的节奏,如周需求评审机制,双周 APP 版本发布,版本回顾会等等。 同时我们需要制定团队的标准和规划,并且在过程中根据需要迭代这些标准规范,常见标准和规范如下:

  • 人员标准:技术职级标准、绩效考核标准、候选人评估标准、干部评估标准
  • 质量标准:代码质量标准、Code Review 标准、测试质量标准、线上质量标准
  • 性能标准:服务端性能标准、客户端性能标准、前端性能标准
  • 安全标准:代码安全标准、数据安全标准、线上安全标准
  • 研发规范:代码风格规范、数据库设计规范、代码分干管理规范、代码提交规范、错误码规范
  • 协同规范:架构规范、技术方案规范、技术文档规范、接口规范

在流程规范和协同之外,研发的效率和质量需要有一些基建来保障,如好用的框架,集成在框架中的静态代码分析,流畅且稳定的构建系统,靠谱的日志系统和监控系统,好用的链路跟踪系统等等。如果公司暂时没有这些,那么先看看业界有哪些,做一些选型后,把最合适的用起来。


除了眼前的苟且,还有架构与远方。

介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现,技术管理等相关话题,紧跟业界主流步伐。

qrcode_for_gh_5d3f534e15fe_344 (1)