分类目录归档:读书

《事务处理原理》

 

概述

年中参与了一个售卖系统的开发工作,开发过程中涉及较多的数据库事务操作以及多层系统之间的状态同步问题。对于事务大方向上的理解,个人觉得需要加强。

查阅相关书籍,发现首推的都是Jim Grey编写的《事务处理》。此书虽然经典,但是篇幅较大(800+页),希望快速了解一些共性原理的情况下,同事推荐了这本《事务处理原理》

在工作之余,挑选了自己较为关注的章节进行阅读并做了一些笔记。

分章节笔记

第1章 简介

事务处理(Transaction Processing, TP)

对于真实世界中的交换产生的记账行为,通过网络连接起来计算机进行处理。

在线事务(Online Transaction)

在线用户执行程序,操作数据库。

ACID

原子性(Atomicity):事务或全部执行,或不执行,

一致性(Consistency):事务保持数据库的内部一致性

隔离性(Isolation):每个事务不影响其他事务

持久性(Durability):故障发生时事务不丢失

通过ACID测试才能称之为一个事务系统。

原子性(Atomicity)

成功称为提交commit,事务异常终止则是abort

对于已提交的事务发现错误的,需要有事务补偿(compensating transaction)机制,考虑到任何事务都有可能失败,设计良好的TP系统需要对各类事务有补偿机制。但是补偿仍有可能不够完备,可以通过其他策略进行修正。

一致性(Consistency)

数据库事务的一致性指的是“内部一致性”,即满足所有逻辑上的约束,不能出现不合理的值。

一致性不仅仅需要事务系统负责,更需要应用程序参与,而且应用程序负主责。

隔离性(Isolation)

隔离性的关键是可串行化。即执行事务集和按顺序逐个执行事务结果一致。

加锁机制是大多数数据库系统保持隔离性的一种方法。

持久性(Durability)

事务执行完成,并一定存入稳定存储器,才能称作实现了持久性。

持久性的主要实现方式之一即将事务更新的副本追加到日志文件中获得的,事务提交时,系统会确保写入日志已经写入磁盘,之后返回给应用程序事务已被提交。如果是数据库程序,实际入库时机不定。事务系统崩溃之后,会通过日志进行恢复,且必须通过日志进行恢复。

两阶段提交(2PC two-phase commit)

解决涉及多个数据库系统的数据不同步的问题。

由事务管理模块控制。执行两阶段提交时,事务管理器发出两轮消息,第一轮通知所有资源将事务结果写入稳定存储中,所有资源均确认已写入后,发出第二轮消息,通知资源管理器实际提交事务。写入的数据量要足以恢复提交前的状态。

第2章 事务处理抽象

集合事务(Transaction Bracketing)

个人理解:集合事务是一组标准的编程模式,提供启动(Start)、提交(Commit)与异常终止(Abort)三个事务命令。

组合事务的两种解决方法

  • 实现Start时只执行第一个Start操作,实现Commit操作时只执行最后一个Commit操作
  • 实现每一个事务组合实现包装器代码,在包装器中进行Start/Commit操作,事务操作编写为元方法

事务标识符

每个事务都应该有个唯一的事务标识符,启动时分配,通过标识符关联全部事务操作。

嵌套事务

嵌套事务在大多数商用系统中不被支持,其表示模式如下:

  • 事务中使用Start命令,则这一事务是其所在事务的子事务
  • 不在事务中使用Start,则这一事务成为顶级事务
  • 顶级的Commit和Abort操作可以影响子事务
  • 子事务Abort只通知父事务,父事务酌情处理
  • 子事务之间是隔离的

必备的异常处理

事务故障的恢复,系统故障恢复。

保存点(Savepoints)

保存点是通过通知资源记录操作完成状态实现回退部分事务的一种机制。保存点只会保存顶级事务带来的影响,当子事务调用保存点记录状态时,子事务存在并发操作的情况下,使用保存点无法回退单一子事务带来的影响。

第3章 事务处理应用程序体系结构

事务处理系统的影响因素

  • 组件是否共享地址空间
  • 地址空间是否有多个线程中的一个线程在执行
  • 是否有硬件、OS或者语言机制保护共享地址空间的程序,免于意外修改内存

事务中间件

提供了API以及各类工具,提供与DB和应用程序的交互功能,对开发人员屏蔽事务操作中的操作系统级别的问题,如多线程、通信和安全性。

存储过程VS事务服务器/中间件

存储过程可以完成事务服务器的工作,然而为什么事务服务器/中间件仍然有市场?

原因在于:

  • 数据库对于新的通信协议、特性的添加相当缓慢且稳定
  • 事务服务器/中间件对开发者更友好(语言,特性,规避问题)
  • 事务服务器可水平扩展性远优于数据库(通过事务服务器更容易扩容)

第4章 队列化的事务处理

队列化的事务处理

  • 队列分为请求队列以及应答队列
  • 队列必须写入到非易失性存储之中
  • TP程序从请求队列获取任务,处理后写入应答队列
  • 客户端和服务端需要在会话中提供足够的上下文,用于恢复和按序处理

队列化的事务处理对于不可撤销操作的处理

对于输出,如果只是涉及到非实物的情况,那么影响并不大。

但是当涉及金钱出入等问题时,需要处理,方法是在出应答队列之前先写入日志,如果没有前期的写入日志的情况,那么说明并没有执行过这一步骤,如果存在,需要人工告知或者通过其他手段确认到底是否可以执行这一操作。总而言之,即先记录动作,再实际操作(带来的问题可能是对用户的不良体验,但是保证了TP系统不会遭受损失)。

个人理解:比如ATM出钞操作,步骤如下:

  1. 由于已经扣款,那么取款机启动一个事务,从应答队列中,取出此次取款操作的返回值,即成功取款;
  2. 本地查看是否有本次取款的物理出钞记录,没有则进行到3,有则终止
  3. 记录本次出钞
  4. 实际打开取钞盒,吐出钞票
  5. 提交事务

第6章 锁定

两阶段锁定(two-phase locking)

一个事务必须在释放其获得的锁之前得到他的锁定。

目的在于不留出因为先解锁后加锁带来的可供其他事物修改已锁定目标的时间段。两阶段锁定生效的有效的前提是事务只通过事务内读取和写入两种操作进行交互,如果借助了其他手段,那么会破坏可靠性。

如果一个执行中的事务都遵循两阶段锁定,此执行就是可串行化的。

死锁解决的唯一方法

终止死锁涉及到的事务之一。

死锁检测的技术

基于超时基于图形的检测。

基于超时的检测易于实现,但是可能会终止实际上并没有死锁的事务,同样的由于基于时间进行控制,也会让死锁持续过久。

基于图形的检测,通过等待图(waits-for graph)这一工具进行,从直观上,节点表示事务,边根据方向A->B,表示A上等待着B上的一个锁定被解除,当锁定解除时,边会被删除,当出现闭环时,说明存在死锁。检查可以是定期检测。同时,基于图形的死锁检测同时也可以在边上设定允许的等待时间,超时的循环存在则可以有效的检验死锁。

然而基于超时的检测并非一无是处,在异构拓扑,以及分布式网络环境中,效果较好。

死锁牺牲品的选择

  • 产生了循环的事务(最易于发现)
  • 锁数量最少的事务(完成最少工作量)
  • 生成日志最少的事务(成本最低)
  • 写入锁数量最少的事务(成本最低)

死锁的循环式重新启动问题(cyclic restart)

被牺牲的事务因为重新启动又触发死锁,导致无法进行。解决办法是可以将启动时间作为牺牲的考虑因素,牺牲最晚出现的事务。

死锁触发的因素

  • 锁转换(lock conversion):多个事务同时要求将同一位置上的读锁转换为写锁,由于两阶段锁定的限制,需要先解锁读锁,但是多个事务互相等待其他事务上读锁的释放,于是死锁;解决方法是对于影响范围先上写锁,确定不需要更改时降级为读锁定,或者使用不和读锁冲突的共享锁模式,先上共享锁,会比先上写锁的方式提高一定并发度。共享锁因为和读锁不冲突,不需要进行解锁等操作,所以不会触发死锁。
  • 锁抖动(lock thrashing):启动太多事务,由于请求锁的数量倍增,会阻塞住大量事务,造成吞吐量减小的情况。

第7章 系统恢复

系统故障的衡量指标MTBF与MTTR

MTBF即Mean Time Between Failures,即系统出现故障前的平均运行时间,MTTR则是Mean Time To Repair,即系统出现故障之后进行修复所用时间。

可用性可以定义为MTBF/(MTBF+MTTR)。

TP系统服务端恢复的原则

非幂等的操作,恢复时对于没有完成的任务需要执行完成,而不是重试。

系统恢复的关注点应该是已执行的事务,这样会简化系统恢复(基于事务的服务器恢复无需复制运行时内存状态,只需通过增量的改动日志进行恢复,不完整的事务不会被理会)。

基于保存点的非幂等操作服务端恢复

基于保存点的非幂等操作的服务端恢复,需要在执行非幂等操作之前,将内存状态保存到非易失性存储中。

这样操作可以使得系统在恢复过程中确定执行非幂等操作时数据的状态,以便从指定的时间点完成任务,防止出现错误的重复操作。

数据库的故障类型

  • 事务故障:事务运行异常
  • 系统故障:主存发生问题
  • 媒介故障:持久化存储器发生问题

数据库的恢复策略

  • 事务故障:恢复到事务执行之前的数据状态
  • 系统故障:中断所有未提交的事务,保证写入已提交事务的结果
  • 媒介故障:与系统故障基本相同

数据库错误恢复的日志格式要点

  • 被更新的页面地址
  • 执行更新事务的标识符
  • 页面被写入后的值(后像)
  • 页面被写入前的值(前像)
  • 冲突操作的实际执行顺序

数据库恢复管理器应该具有的三大操作

  • 提交:原子的将更新后数据写入数据库,不可撤销
  • 中断:将事务带来的数据影响还原,不可撤销
  • 重启:中断故障时所有未提交的的事务,写入已提交的事务尚未同步到数据文件中的数据。这一个操作必须是幂等的

预写日志协议

先改动数据文件,后写入前像日志,在第二步出现错误时,系统恢复,会引起前像丢失的问题,无法恢复。

预写日志协议的定义是:不要讲未提交的更新输出到稳定数据库中,直至其前像日志记录被输出到日志之中。

通过这一方式,数据库可以实现异常终止,明确恢复时可以关闭的事务,以及需要补充写入数据文件的部分。

No-Steal方法是一个简化的规避上述问题的方法,即未提交的改动全部记录到日志之中,事务提交之后才将改动写入到DB之中(问题:如何保证提交之后,数据写入稳定存储和其他事务读取了正确的数据?事务已提交,结果就能被读取,未写入到稳定存储中,也需要能被读取?)。

提交时的强制规则

与预写日志协议相冲突,这一规则的定义为:在事务所有已更新数据的后像写入到稳定存储之前,不能提交事务。

故障恢复方法(Shadow-paging)

核心思想是维护两份数据,数据库中的数据只存储已提交的事务,提交事务的操作即将数据指向已写入稳定存储中的状态副本(shadow page)。

所谓Shadow page可以看做是数据的目录,会指向实际的数据页面文件,在Shadow page完成指向之后,数据库会更换shadow page的指向,之前的关联关系就会被废弃。

中断事务因为没有做实际的改变(指向关系没有变动),所以可以直接通过废弃主存中的修改数据以及已写入稳定存储的数据,无需做特别恢复操作。

Shadow-paging方法在书中提到在商业系统不常用的原因,虽然简单,但是提交时直接将整个页面写入稳定存储,需要耗费大量的IO操作,涉及大量的随机写,在机械盘时代必然会有其劣势。

基于日志完成中断

基于日志完成中断操作时,事务管理器需要从日志记录的的最后一个更新开始,用前像替换已更改的数据文件。

实现中断操作的问题在于,顺序查找日志中的更新事务效率低下,所以在需要实现一份事务与事务最后一条执行日志的匹配关系,同时事务的每条日志也要记录事务的上一条位置的指针(文件指针?),便于从后往前还原前像。

基于日志完成恢复

基于日志完成恢复,仍然是通过从后向前扫描日志进行,直到完成到检查点。

原因在于,最后一条日志可以明确事务是否已提交。中断的事务会被丢弃,并恢复前像;已提交的事务则会检查并写入数据;而运行中的事务,则会检查并写入后像,继续运行这一事务。

恢复时会阻塞所有新事务请求。

日志恢复速度优化——模糊检查点

核心在于,正常运行时写入检查点之前,脏页面已经全部写入。写入操作在系统空闲时进行。由于写入新检查点的前提是之前一个检查点之前数据已经完成写入,所以检查需要从第二个检查点之后进行。

第8章 两阶段提交

两阶段提交的处理对象

应对多个资源管理器的事务操作。

2PC的四个通信指令

REQUEST-TO-PREPARE:协调者->参与者

PREPRARED:参与者->协调者(失败则发送NO)

COMMIT:协调者->参与者

DONE:参与者->协调者

然而,任意阶段出现问题时,协调者可能还会发出ABORT指令,让参与者放弃事务,解锁资源。

2PC PREPARE

2PC中PREPARE所做的操作,是持久存储了事务的余像(afterimages)。

参与者与协调者的等待时机

参与者需要在不明确收到COMMIT/ABORT指令时进行等待(参与者可以请求协调者要求指令状态)。

协调者则需要在未收到DONE消息时进行等待(然而协调者还会定时要求参与者反馈状态)。

参与者与协调者写入日志的时机

参与者:PREPARED与DONE发送之前

协调者:REQUREST-TO-PREPARE与COMMIT发送之前(REQUREST-TO-PREPARE可以优化不写入,COMMIT日志存在的前提下,可以给参与者请求执行指令时有明确回复)

2PC可以使用三轮通信的条件

  • 只有一个参与者且参与者没有独立的准备阶段

可以在REQUEST-TO-PREPARE这一个阶段完成之后,将协调者的角色转移到参与者,通过新的协调者(即参与者)完成本地事务之后,发送COMMIT,驱动新参与者(原协调者)发送DONE消息,完成整个事务流程。由于角色变更,新协调者(即参与者)必须要等待DONE消息

合作终止协议

处理参与者者宕机恢复而此时协调者也宕机的情况,通过了解其他参与者收到的通知,决定本参与者执行的操作。参与者告知自己收到的状态,未收到REQUREST-TO-PREPARE的情况的,需要回复ABORT指令,而已PREPARED的,因为不知道原协调者的指令,需要回复UNCERTAIN。

《从自我苛求中解放出来》

 

概述

《从自我苛求中解放出来》是弗雷德里克•方热 (Frédéric Fanget)的一本出版书籍。这位任教于法国里昂第一大学的精神科医生、心理治疗师也是一位畅销书作家。

微博上看到@郝景芳推荐,决定购入阅读。

想要让所有人都能够满意,希望能做好每一件事,似乎是很多人所期望的。但是事与愿违的情况会远比想象中的做,太过于在意他人的感受,陷入对自己的不完美的懊悔之中,给自己带来了痛苦。

各个地方不乏对于悦纳自我,接受缺陷的,拜托焦虑这类的说辞,但是具体的实现方式却语焉不详,这本小书的优势就在于此。没有说教的成分,语言上的通俗让人易于接受,而篇幅也比较适中。

个人的内心的正确认识是个很困难的事情,另外没有学习过类似的课程,自己尝试一下分析消化读到的内容。

笔记

认同书中最后提到的一个等式:

尤其是身处的环境,多次证明了在当前的情况下,选择给生活带来的影响相当巨大,职业上来说更是如此。看到了选择带来的巨大差距之后,焦虑的放大系数会变得更大,很多时候会更加的畏首畏尾。

然而做出选择并不一定是让自己最愉快的,往往都会被内心自我苛求的声音给勒索,原本能保护自己的焦虑成了伤害的来源。

这个时候使用工具一定程度上可以帮助分解问题,找到办法打破或者改变恶性循环。

认知概念化

作者提出的认知概念化方法,一个实现的方式,就是通过循环图的形式将其模型化,在可视化问题的各个阶段和状态流转之后,辅助认识问题。

做出选择一般都事出有因,大多数是来源于一个人生准则,比如完美主义,书中举例一位以“做事求赞”为生活准则的女性的例子(人生准则细则的原文是必须做出超乎寻常的事),例子的主角为了避免被人否定,而季度的追求完美主义,希望万事都是做的完美。

通过认知概念化的方法,会发现造成例子中的主角内心不自由的根源在于扭曲了信心和价值感的获取和渴望出色的完成事情的关系,在周而复始的过程中,这个扭曲会不断的加强,从而绑架了个人。

实现认知概念化的方法,简单概括为:

  • 确定具体情境
  • 找到这一情境下行为准则
  • 找到对行为的影响
  • 找到对情绪的影响
  • 推导出认知扭曲的结果
  • 最后总结出对个人的影响

生活中的一些场景,个人按照这一方法分析,如内向的人被拉去聚会结识新朋友,可以是:

  1. 具体情境:结识新朋友
  2. 行为准则:必须外向,否则不会受欢迎
  3. 对行为的影响:尝试与他人热烈的沟通,获取认同
  4. 对情绪的影响:满足
  5. 认知扭曲:因为变得外向,所以能够结识新朋友
  6. 对个人的影响:要改变自己内向的状态,迎合大家

事实上,人际关系的建立,个人也一定程度上决定于个人的内在特质,内向外向的性格固然影响巨大,但是因为这一人生准则而痛苦不堪,是没有必要的。

带来问题的人生准则

什么样的准则可能会带来问题?

简答来说,如下句式的可能会带来问题:

  • 必须
  • 应该
  • 如果……才会……

更容易的一个概括方式,大概就是书中提及的,美国认知疗法先驱Alber Ellis提出的musturbation了,第一个音节的must概括了这类认知的特性,即一个人给自己的定下的不可改变的人生准则。

在与准则的共处过程中,如果当事人被压制到毫无回旋余地,那么这些准则就变得有害。痛苦也就随之而来。

概念化模板

在说明这一个工具之前,先说两个概念的个人理解:条件认知模式无条件认知模式

条件认知模式是受到外界因素的影响而产生的对事物的看法,而无条件认知模式则是自发的产生的对事物的看法。条件认知模式的更易于接受和理解。

给个人带来困惑的问题实际上可以总结出一个循环,即处理A问题时,如果选择行为B则带来不良后果C,会影响我的正面情绪D,增强负面情绪E,最后在类似A问题再次到来时,心理上会推广这一个循环的适用范围,迫使自身选择不利于自身的行为B。对于让自己产生焦虑的问题,可以尝试总结出这一个循环,看看是否存在口是心非的情况,解决的方法是直面现实,从保护自己的利益的方面做出考虑。

童年生活中往往会影响无条件认知模式,这类焦虑产生时,对自身提问是能解决问题的好办法,多问为什么可以帮助分清现实和内心虚构出来的影响。

总结

选择和焦虑共处,遭遇焦虑时寻找出焦虑产生的循环,针对当中的准则多问为什么。

肯定自己,勇敢说不,是两件最艰难的事情之一。

最后,最重要的,不要过度关注焦虑本身,思绪被焦虑占据,就没有了生活的空间。

《格鲁夫给经理人的第一课》

 

概述

创业维艰》中多次提到格鲁夫的这本著作,作为作者霍洛维茨称赞的书籍,自然是需要阅读一番。

安迪·格鲁夫作为一名匈牙利移民,经过自己积极努力的学习,成为了一名工程师,作为Intel的第三名员工,参与了Intel的创建,历经工程师、工程经理,最终作为Intel的总裁/CEO,成就了Intel的故事。格鲁夫已于2016年3月21日逝世,然而这本1995年出版的书籍再版多次,影响可谓众多。

格鲁夫最为我熟悉的一点,应该是Andy and Bill’s Law,即Andy gives, Bill takes away,直到现在,制程的进步和技术的突破终于让CPU的性能似乎超过了操作系统和应用软件带来的消耗。

书名直接指向“经理人”,但是格鲁夫所指的经理人,并不单指是管理工作者,格鲁夫认定的中层经理人,也包括了解工作所需技能,运用经验、学识以及技术影响他人工作的人,也就是技术支持经理人。个人认为作为有一定的工作年限的工程师来说,一定程度上与这个概念有所契合。

书名虽然是指向管理,但是书中观点也许能让自己从另一个角度观察自己的工作。

笔记

新环境的规则是:第一,事情发生的速度越来越快;第二,事情总有人能做,如果你不做,我们就另请高明。

越来越充满危机感的工作环境。

让混沌丛生,然后掌握混沌

产出导向管理;团队意识;管理杠杆率;

本书提出的三个基本概念

一个经理人的产出,便是他所管理或影响所及的部署工作的成效和综合。

必须按预定的时间、可接受的品质以及可能的最低成本,按照顾客的需求制造及运输产品。

格鲁夫对生产的一个定义,程序员的工作中,指向的应是里程碑,代码质量,开发工时,实现产品需求。

可选的指标也许不计其数,但除非“每一项指标个针对不同作业目标评估”,这整套指标才会发挥功效。

通过“指标配对”的方法避免反应过度。

指标运用的第一条原则是,“有总比没有好”。

指标运用的第二条原则是,一个好的指标应该是用来衡量具体且可计算的事情的。

上述观点与SMART部分重合

员工永远会将交差的时间拖到最后一秒。

个人认为这是和人的惰性做斗争,同时发生了这类事情,也可能会发现糟糕的时间规划。

“监视器”的执行成本比“海关”低。广设关卡可以提升产品的品质,但是应该设多少则很难有定论。

提到的“监视器”指的是抽查的方法,“海关”则是普查。毋庸置疑,普查带来的成本必定是巨大的,追求质量也不能忽视效率。事必躬亲的产出效果不一定理想,正常情况下,事情越大,个人能力会显得不足,当然也会有例外。

必须了解哪些活动有最高的杠杆率。

时间成本会越来越大,追求事半功倍是必然。

对于大多数的经理人而言,最重要的信息往往来自于简短而非正式的谈话。

书面报告的作用在于建立数据文件、过滤并确认纷至沓来的各种信息,且要避免漏网之鱼。

报告用来表示一个人的自律,远胜于它咋传递信息上的作用。

考虑口头尽快同步信息,书面文字落实,定期重复检查。

对于报告的观点,认同。

如果你的授权人猜不透自己已被授权或不明白被授权的范围,将会有极高的负杠杆率。

不信任感与不明确的负面影响。

没有完备的监督计划的授权等于渎职。你绝对不能完全的抽身,即使你已经授权,你还是的负成败责任。全程监督整个被授权的案子是确保结果进入任意的唯一方法。监督不是干涉,而是通过不是的检查,来确定活动的进行移入预期。因为监督你熟悉的工作比较容易,所以如果有机会,你应该把自己熟悉的工作授权给他人。

理智让你松手,但情感上你可以能老大不愿意。

手到擒来的熟练工作,复杂度不高的就应当交出,获取更多的时间完成更重要的工作。不需要通过这些来找存在感。

找出限制步骤

类似的工作集中一起做

安排好你的日程表

以上是格鲁夫提到的时间管理的几个方向。限制步骤即必须完成的工作,了解清楚可以重新安排整个工作过程。类似的工作集中一起做解决中断带来的成本问题。

安排日程表上来说,个人觉得,对于超过工作负荷的事说不相当重要,这是对整个工作负责,可以有重新安排的空间。承担更多的责任当然是必须的,但是把事情搞砸是更不能接受的,对个人来说,也是灾难性的。

会议是从事管理工作必经的媒介。

格鲁夫认为会议分为两种,一种是信息交流的的“过程导向”型会议,如例会;一种则是解决特定问题的“任务导向”会议,是随着工作的变化而随时发生的。

会议强度和熟悉度负相关。

对于一对一会议,格鲁夫认为应当让会议对象承担更重要的角色,由会议对象掌握会议议程,鼓励提出隐藏问题(帮助提早发现解决),让会议对象知无不言。同时也需要有会议纪要(会议纪要可以一定程度上表示已关注,同时也方便回顾)。

决策权不再完全由职位决定,另一种掌握知识和技能到那时职位不高的决策新秀将脱颖而出。

决策权的指定和执行应交给最低层级。

我们这个产业,必须要结合具有“知识力”及“权利”的两种人一起决策,如果我们没有办法让两种人合作以提升决策品质,那企业的衰亡就是迟早的事。

工具和外部环境的变化会带来技术技能上的盲区,很难永远跟上这类变化,拥有专业知识的人员的作用正是跟上变化。

后两句如字面意思。

当一群职位相当的人要开会时,总需要一个职位较高的人与会。不见得最能干或者最具有专业知识,但是他能控制会议的进行。

同级、同类害怕成为异类。

在指定政策之前,经理人应对一下6个问题的答案了然于胸:1.决策的内容。2.决策的问题。3.决策人。在制定决策前应先向谁咨询。5.谁对此决策一言九鼎,或是能全盘否定。6,谁应该在决策指定行后被告知。

如字面意思。

我见过太多人,他们了解现状与理想之间的差距,并且努力想要缩小此察觉,但他们不明白今日他们所面临的问题,经常是源于过去规划的失误。

《创业维艰》

 

概述

创业维艰》是今年来读过的印象较为深刻的书籍。

作者本·霍洛维茨作为硅谷投资教父级的任务,本身是一个成功的创业者,带领自己创业的LoudCloud公司活过了互联网泡沫破碎的时代,本人也是个成功的投资家,Facebook, Instagram, Twitter, Airbnb这些赫赫有名的公司都有他的手笔。

书中提到的一些观点个人读到之后觉得较为有趣,虽然并不身处于创业公司,但是读到之后个人还是引发了自己的思考,了解了创业这个方向的另一面。书中作者的措辞和举例的诚恳态度相当让人印象相当深刻。

成功者的经历几乎无法复制,但是成功者的经验却是可能会后来者规避更多陷阱的有效参考。

在Kindle上入了中信的译本,对自己觉得有意思的一些观点做简要的记录。

书摘

寻找一个统一市场,其中只要有一个投资者点头,即可成功。即便30位投资者即便全都摇头拒绝也无关紧要。

笔记:毕竟拥有十足信心的人在少数,即便是到了投资者这个级别,依然也有跟风的现象存在。

每当大公司打算事实一个计划时,该计划总会落到某个人身上,而此人却极有可能延误整个计划。如果此人是工程师,他也许会因为等待上层觉得而踌躇不前;如果此人是管理者,他也许会因为自己无权做出关键性购买决定而犹犹豫豫。这些看似微不足道的踌躇和犹豫很有可能会造成致命的延误

笔记:指令要明确,分工也需要具体,不能存在灰色地带。

大多数管理书籍的重点都是如何正确做事,不要把事情搞砸。但我的经验却是,把事情搞砸之后,如何深刻的理解你必须要做的那些事情。

笔记:然而很多时候个人代替从搞砸了事情中的吸取教训所做的事情却是悔恨与烦恼,并无用处。多人已经提过类似观点,戴尔也说过试错并学习(然而戴尔现在……)。

自己的员工要自己亲自辞退,不能将这项工作推给人力资源部门或某个更严厉的同事,不能像电影《在云端》中雇佣一家外包公司完成。

笔记:last day会被记住。

正确解雇高管的第一步是,搞清楚自己为什么为公司招错了人

如果这名高管是由董事会成员举荐而来的,打电话个人通知就显得尤为重要

说话要果断,不要给讨论留下悬念

向董事会宣布最新的人事变动信息时,一定要用积极正面的方式,不要给人一种“一脚将高管踢出公司的感觉”

此时,你也许会担心员工们曲解消息,以为公司陷入了困境。不要在意这些反应

笔记:不做评论,基本不会用到这些内容,但是最后一条让人对这类事件可以用一个新的角度去看待管理者们的表现。

人,尤其是那些创造事物的人,只愿意听好消息。

笔记:码农的天然乐观是个毒药,要学会接受坏消息。

不要花时间懊悔过去,要将所有时间花在自己可以做的事情上,因为说到底,没人会在意。

笔记:一针见血,懊悔过去当真是对当前的不负责,累计了更多的债务。再次强调,没人会在意自己做错的事情。

和平时期的世界与你每天必须为生活苦苦挣扎的世界完全不同。和平时期,人们有时间关注言行是否得体、长远的文化影响以及人们的情感这类问题。而在你为生活苦苦挣扎的时期,最重要的是奋勇杀敌,带领自己的队伍安全抵达目的地。

笔记:想起《鸿门宴》,沛公曰:“今者出,未辞也,为之奈何?”樊哙曰:“大行不顾细谨,大礼不辞小让。如今人方为刀俎,我为鱼肉,何辞为!”。活下去是第一要素。理解了某些情况下领导的做法。

我们要依次管理好人、产品和利润。

笔记:人生产产品,产品带来利润?

在科技公司里,一旦员工流失,就会出现螺旋式的循环:公司价值下跌,最优秀的员工流失,公司价值继续下跌,最优秀的员工继续流失。这种恶性循环很难逆转。

笔记:论公司的倒掉。

未完待续。