如何激励员工?

3251 2019-04-11 22:14

动机和激励是绩效管理的核心。没有激励,员工没有动机把事情做好,所有的反馈和培训都是白费力气。

领导对员工的尊重与员工的激励程度正相关

冒犯行为会直接打击员工的动机和绩效,所以经理需要遏制冒犯行为,可以这样做:

  1. 自己作出表率,上行下效。
  2. 维护员工的自尊。公开表扬,私下批评。
  3. 雇佣尊重人的员工,不姑息坏行为。遇到问题反馈要及时。

激励主要来自两个方面:外在和内在

  1. 外在的奖励——金钱 (升职加薪奖金)

    1. 这种奖励不一定会提高员工的绩效。
    2. 通常效果短暂。
    3. 整个团队的工作很难分清楚贡献的多寡,奖励多少才算合适对每个人来讲标准都不一样。实际上,大多数员工的主要关注点在于公平,作出金钱奖励的时候一定要注意公平性和一致性(consistency)。
  2. 内在的奖励——满足感(成就感、控制感、被感激感、智力上的提升、技能提高、自治、达成挑战)

    1. 一定要注意,这种奖励要注意因人而异

怎么做到给人以内在奖励呢?

  1. 认可他的工作。“认可的关键在于让人感受到他的与众不同”。每个人得到同样的东西,每个人就不会有与众不同感。

    1. 每个人对认可的来源的重视程度不同。来自同事?在同事面前公开表扬他。来自客户?发一张客户的感谢信。来自专业?发专业奖项。来自老板?1:1 的时候生动地描述他对团队的重要性。
    2. 按照性格认可。内向外向?公开私下?如果不清楚,可以直接问对方。
    3. 认可的频率要高,至少两周一次。
    4. 手写的奖励成本低但是效果奇佳。
  2. 提供决策权

    1. 人们喜欢拥有感和控制感
  3. 提供挑战

    1. 挑战难度越高,完成的成就感就越高。
    2. 提供做没做过的事情的机会,帮助人开发新技能。要注意,前提是他们有相关的天赋和技能,而不是完全从零开始。

公司

  • 总共成立四年,前两年都在写代码,最近一年半有一两百家企业在用
  • Infra 在中国做很有优势,因为中国市场大,公司快糙猛拿来主义,infra 的好东西能够很快地被用上
  • cofounders 里面没有 db 的经验
  • open source 模式是未来,如果是闭源只能一家一家谈
  • 最重要的商业决策:不在于算法有多nb 团队有多厉害,护城河的关键在于 1)社区 2)mysql 接口 (借用了 mysql 的社区开始,SQL 的支持很重要,比如连Kafka, Spark都支持 SQL )

TiDB 数据库原理

越nb的工程师越喜欢高性能,认为越快越好。但是 TiDB 的首要目标不是做到最快,而是做到 Availability reliability 稳定性 IO和 无限扩展。高性能的成本太高,要根据用户的硬件优化。但是这里是通用的数据库,不可能去优化各种场景。简单留给用户,复杂留给自己(跟AWS意见相反)。

认为 eventual consistency 是个伪概念,实际上就是没一致性或者弱一致性。比如 cassandra WRN 设置好了,但到底过多久 能够resolve?不确定。太复杂,用户最好不需要知道操心这些复杂的设置。

跑分不是唯一的指标,TPCC/TPCH 分数高对实际没有太多指导意义。数据库是磨出来的。比如第一家客户,游戏公司,居然创建了3万张表,json 的 meta 信息连起来非常慢。

构架上不是 P2P,而是不同角色分得很清楚。

KV 用的是 RocksDB 但是典型的 LSM tree 的写放大是15倍,这里优化到 value 拆出来,解决写放大的问题。

支持 MySQL 的client,也支持 SparkSQL 的读。

SQL layer 没有用 MySQL 的模块。一开始有试过,但是1)下面很难分布式 2)代码太烂很难改。魔改的话,半年能做;但是长期的维护成本更高。重做不麻烦,都重构了三次了。这里用 Go 比用 C/C++/Rust 重构更方便。

一开始只想做 F1只做sql,和 CockroachDB 合作,后来他们往sql这边做,这边就只能往storage 做

挖了 Rust core team 的两个人。rust 很难招人,一般是招 C++的人然后转rust,他们会觉得很多脑袋里的约定编译器帮你搞定了。

不要低估造工业级轮子的难度。用 grpc,raft,rocksdb的好处是,如果业界有新的进展,会直接让使用者收益。

Chunk (region) split 做了两个月,merge 做了三年。merge 做了形式化证明。

Tech 趋势

为什么是现在?

  1. hardware
  2. Hot / cold data -> warm data
  3. Log is the new database

Everything is pluggable , 顶层 api 不变,下面即插即用可替换

Distributed Transaction

  • 2PC is the only option
  • challenges: reduce round-trips

Multi-tenancy achieved by kubernetes

中国 Biz Trend

  1. 中国速度,说上就得上
  2. 对新技术服务赋能业务的期望更高。二三线城市的公司或者非BAT用新技术与巨头斗争。必须能够解决使用者的技术焦虑。
  3. 基础软件人才储备逐渐变强。P产能CAP 对技术 content marketing 做了很多贡献。
  4. 一些核心场景(银行核心系统)敢于使用国产技术。
  5. PingCAP路径:开源(互联网/社区) <-> 商业化

为什么有这种框架?

  • 为了在更短的时间内处理更多的数据。
  • 统一处理分布式系统中的容错问题。
  • 将任务简化抽象以应对多变的业务要求。
  • 分别适用于有界数据集(批处理)和无界数据集(流处理)。

批处理与流处理的发展史简介

  1. Hadoop 与 MapReduce。谷歌让批处理在一个分布式系统中像 MapRduceresult = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)一样简单。
  2. Apache Storm 与有向图拓扑结构。MapReduce 不能很好地表示迭代算法。因此,内森·马兹(Nathan Marz)将流处理抽象成一个由 spouts 和 bolts 组件构成的图结构。
  3. Spark 内存计算。辛湜(Reynold Xin)指出 Spark 在处理相同数据的时候比 Hadoop 少使用十倍机器的同时速度却快三倍
  4. 基于 Millwheel 和 FlumeJava 的谷歌数据流(Google Dataflow)。谷歌使用窗口化API同时支持批处理与流处理。
  1. Flink 快速采纳了 Google Dataflow 以及 Apache Beam 的编程模式。
  2. Flink 对 Chandy-Lamport checkpointing 算法的高效实现。

这些框架

架构选择

若要用商业机器来满足以上的需求,有这些热门的分布式系统架构……

  • master-slave(中心化的):Apache Storm + zookeeper, Apache Samza + YARN
  • P2P(去中心化的):Apache s4

功能

  1. DAG Topology 用来迭代处理 -例如Spark 中的 GraphX, Apache Storm 中的 topologies, Flink 中的 DataStream API。
  2. 交付保证 (Delivery Guarantees)。如何确保节点与节点之间数据交付的可靠性?至少一次 / 至多一次 / 一次。
  3. 容错性。使用cold/warm/hot standby, checkpointing 或者 active-active 来实现容错。
  4. 无界数据集的窗口化API。例如 Apache 的流式窗口。Spark 的Window函数。Apache Beam 的窗口化。

不同架构的区别对照表

架构 Storm Storm-trident Spark Flink
模型 原生 微批量 微批量 原生
Guarentees 至少一次 一次 一次 一次
容错性 记录Ack 记录Ack 检查点 检查点
最大容错
延迟 非常低
吞吐量

免责声明:以下所有内容均来自公共资源或纯粹原创。 这里不包含优步的涉密内容。

要求

  • 为全球的交通运输市场提供服务
  • 大规模的实时调度
  • 后端设计

架构

uber architecture

为何要微服务?

Conway定律 软件的系统结构会对应企业的组织结构。

单体 服务 微服务
当团队规模和代码库很小时,生产力 ✅ 高 ❌ 低
当团队规模和代码库很大时,生产力 ❌ 低 ✅ 高 (Conway定律)
对工程质量的要求 ❌ 高 (能力不够的开发人员很容易破坏整个系统) ✅ 低 (运行时是隔离的)
dependency 版本升级 ✅ 快 (集中管理) ❌ 慢
多租户支持 / 生产-staging状态隔离 ✅ 容易 ❌ 困难 (每项服务必须 1) 要么建立一个staging环境连接到其他处于staging状态的服务 2) 要么跨请求上下文和数据存储的多租户支持)
可调试性,假设相同的模块,参数,日志 ❌ 低 ✅ 高 (如果有分布式tracing)
延迟 ✅ 低 (本地) ❌ 高 (远程)
DevOps成本 ✅ 低 (构建工具成本高) ❌ 高 (容量规划很难)

结合单体 代码库 和微服务可以同时利用两者的长处.

调度服务

  • 由geohash提供一致的哈希地址
  • 数据在内存中是瞬态的,因此不需要复制. (CAP: AP高于CP)
  • 分片中使用单线程或者锁,以防止双重调度

支付服务

关键是要有异步设计, 因为跨多个系统的ACID交易支付系统通常具有非常长的延迟.

用户档案服务和行程记录服务

  • 使用缓存降低延迟
  • 随着 1) 支持更多的国家和地区 2) 用户角色(司机,骑手,餐馆老板,食客等)逐渐增加,为这些用户提供用户档案服务也面临着巨大的挑战。

通知推送服务

  • 苹果通知推送服务 (不可靠)
  • 谷歌云消息服务GCM (它可以检测到是否成功递送) 或者
  • 短信服务通常更可靠

任务相关成熟度

22958 2019-02-07 16:10

安迪格鲁夫强调:管理者最重要的责任是激发他的下属做出最佳的表现

不幸的是,没有一种管理风格适合各种场景下的所有人。找到最佳管理风格的基本变量是下属的任务相关成熟度(TRM)。

部属的工作成熟度 有效的领导风格
组织化; 以任务为导向; 面向细节; 准确地指出“什么时候-什么事情-怎么做”的细节模式
以人为本; 给予支持,“双向沟通”模式
以目标为导向的“监控”模式

一个人的任务相关的成熟度取决于具体的工作项目,它的改进需要时间。 当任务相关的成熟度达到最高水平时,这个人的知识水平和积极性就会达到一定高度,让他的管理者能够顺利地把工作委派给他。

这其中的关键是管理方式无所谓好坏,只有有效和无效

硅谷IO

软件工程与创业
© 2018 硅谷IO
Built with ❤️ in San Francisco