阿里云块存储团队卓越工程实践

2022-10-11
浙江
本文字数：18847 字
阅读完需：约 62 分钟

作者：彭文文、石超、张小路

“我背上有个背篓，里面装了很多血泪换来的经验教训，我看着你们在台下嗷嗷待哺想要这个背篓里的东西，但事实上我给不了你们”，实践出真知。

这是阿里云块存储团队内部的一次新人培训材料，内容源自老同学们的踩坑经验，总结成案例和方法分享给大家，实践和方法论不限于分布式系统，希望对读者有所启发。本文主要包括以下三个方面的内容：

编码习惯（开发、测试、Review，Bad/Good Case）
研发流程（源码控制、每日构建、缺陷管理）
实践方法（效率工具、新人踩雷、学习推荐）

一、编码习惯

Ugly is easy to identify because the messes always have something in common, but not beauty.
—— C++ 之父 Bjarne Stroustrup
代码质量与其整洁度成正比。
——《代码整洁之道》作者 Robert C. Martin

1.1 开发

别人眼中的软件系统犹如灯火辉煌的摩天大厦，维护者眼中的软件系统犹如私搭乱建的城中村，我们要在这座城中村里生存，一直维护这些代码，添加新功能等，要让大家生活得更好，我们写代码不仅追求正确性，还有健壮性和可维护性。

图 1 开发理想与现实

要点 1 ：语义简单明确

这是块存储 SDK 的一段代码，判断限流目标值是否合法；写代码时考虑读者，优先采取易于读者理解的写法。

#define THROTL_UNSET      -2#define THROTL_NO_LIMIT   -1bool throttle_is_quota_valid(int64_t value){    // 复杂的判断条件    // 请你在三秒内说出 value 如何取值是合法的？    if (value < 0 && value != THROTL_UNSET && value != THROTL_NO_LIMIT)    {        return false;    }    return true;}bool throttle_is_quota_valid(int64_t value){    // 这是修改后的代码，value 取值合法有三种情况，一目了然    return value >= 0 || value == THROTL_UNSET || value == THROTL_NO_LIMIT;}

复制代码

要点 2 ：简洁 ≠ 代码短

这是块存储的一段代码，它遍历回收站中的所有文件，统计每种介质上文件最早的时间戳；简洁≠代码短，复杂的问号表达式反而不如 if..else 方便理解。

void RecycleBin::Load(BindCallbackR1<Status>* done){    ......    FOREACH(iter, fileStats)    {        RecycleFile item;        Status status = ParseDeletedFileName(iter->path, &item.timestamp);        if (!status.IsOk() { ...... }        item.fileName = iter->path;        item.size = iter->size;        item.physicalSize = iter->refCount > 1 ? 0 : iter->physicalSize;        ......        // 这是修改前的代码        // earliestTimestamp[item.medium] =        //     item.timestamp != 0 && item.timestamp < earliestTimestamp[item.medium] ?        //     item.timestamp : earliestTimestamp[item.medium];        // }        // 这是修改后的代码        if (item.timestamp != 0 &&            item.timestamp < earliestTimestamp[item.medium])        {            earliestTimestamp[item.medium] = item.timestamp;        }    }    ......}

复制代码

要点 3 ：提前返错

提前返错能减少主体逻辑的缩进数量，让主体代码逻辑显得更醒目。

Bad Case 如下：

void RecycleBin::Load(BindCallbackR1<Status>* done){    ......    FOREACH(iter, fileStats)    {        RecycleFile item;        Status status = ParseDeletedFileName(iter->path, &item.timestamp);        if (!status.IsOk() { ...... }        item.fileName = iter->path;        item.size = iter->size;        item.physicalSize = iter->refCount > 1 ? 0 : iter->physicalSize;        ......        // 这是修改前的代码        // earliestTimestamp[item.medium] =        //     item.timestamp != 0 && item.timestamp < earliestTimestamp[item.medium] ?        //     item.timestamp : earliestTimestamp[item.medium];        // }        // 这是修改后的代码        if (item.timestamp != 0 &&            item.timestamp < earliestTimestamp[item.medium])        {            earliestTimestamp[item.medium] = item.timestamp;        }    }    ......}要点3 ：提前返错提前返错能减少主体逻辑的缩进数量，让主体代码逻辑显得更醒目。Bad Case如下：Status Foo(){    Status status = Check1();    if (!status.IsOk())    {        return status;    }    else    {        status = Check2();        if (!status.IsOk())        {            return status;        }        else        {            status = Check3();            if (!status.IsOk())            {                return status;            }            else            {                DoSomeRealWork();                return OK;            // 四层潜套 if            }        }    }}

复制代码

Good Case 如下：

Status Foo(){   Status status = Check1();   if (!status.IsOk())   {       return status;   }   status = Check2();   if (!status.IsOk())   {       return status;   }   status = Check3();   if (!status.IsOk())   {       return status;   }   DoSomeRealWork();   return OK;}

复制代码

要点 4 ：利用析构函数做清理工作

利用 C++ 析构函数做清理工作，在复杂冗长代码中不会漏掉。典型的清理工作有执行回调、关闭文件、释放内存等。

Bad Case 如下：

void Foo(RpcController* ctrl,         const FooRequest* request,         FooResponse* response,         Closure* done){    Status status = Check1(request);    if (!status.IsOk())    {        response->set_errorcode(status.Code());        // 第一处        done->Run();        return;    }    status = Check2(request);    if (!status.IsOk())    {        response->set_errorcode(status.Code());        // 第二处        done->Run();        return;    }    DoSomeRealWork(...);    // 第三处    done->Run();}

复制代码

Good Case 如下：

void Foo(RpcController* ctrl,         const FooRequest* request,         FooResponse* response,         Closure* _done){    // 仅一处，不遗漏    erpc::ScopedCallback done(_done);    Status status = Check1(request);    if (!status.IsOk())    {         response->set_errorcode(status.Code());         return;    }    status = Check2(request);    if (!status.IsOk())    {         response->set_errorcode(status.Code());         return;    }    DoSomeRealWork(...);}

复制代码

要点 5 ：用朴素直观的算法

这是块存储旁路系统的一段代码，它根据垃圾比对数据分片进行排序；在非关键路径上，优先使用朴素直观的算法，此时代码可维护性更重要。

void CompactTask::checkFileUtilizationRewrite(){    // 此处采取朴素的排序算法，并未采取更高效的 TopK 算法    std::sort(sealedFilesUsage.begin(), sealedFilesUsage.end(), GarbageCollectionCompare);        int64_t sealedFileMaxSize = INT64_FLAG(lsm_CompactionSealedMaxSize);    int32_t sealedFileMaxNum = INT32_FLAG(lsm_CompactionSealedMaxFileNum);    int64_t targetFileSize = 0;    int32_t sourceFileCnt = 0;                                                                                                                                          // 前者简单清淅，并在几十个 File 中选择前几个文件的场景并不算太慢    FOREACH(itr, sealedFilesUsage)    {        LogicalFileId fileId = itr->fileId;        const FileUsage* usage = baseMap->GetFileUsage(fileId);        const File* file = fileSet->GetFile(fileId);        targetFileSize += usage->blocks * mBlockSize;        sourceFileCnt++;        if (targetFileSize > sealedFileMaxSize || sourceFileCnt > sealedFileMaxNum)        {            break;        }        mRewriteSealedFiles[fileId] = true;    }    ......}

复制代码

要点 6 ：用轮循代替条件变量

这是块存储 IO 路径的一段代码，从内存中卸载数据分片时等待在途 inflight 的 IO 请求返回；在非关键路径上使用简单的轮循代替精巧的条件变量同步，代码简洁且不容易出 bug。

void UserRequestControl::WaitForPendingIOs(){    erpc::ExponentialBackoff delayTimeBackOff;    delayTimeBackOff.Reset(            INT64_FLAG(lsm_UnloadWaitingBackoffBaseUs),            INT64_FLAG(lsm_UnloadWaitingBackoffLimitUs),            INT64_FLAG(lsm_UnloadWaitingBackoffScaleFactor));       // 轮循等待在途的请求返回    // 请思考如何用条件变量实现精确的同步    while (!mWriteQueue.empty()|| !mReadQueue.empty())    {        uint64_t delayTime = delayTimeBackOff.Next();        PGLOG_INFO(sLogger,                  (__FUNCTION__, "Waiting for inflight requests during segment unload")                  ("Segment", mSegment->GetName())                  ("Write Requests", mWriteQueue.size())                  ("ReadRequests", mReadQueue.size())                  ("DelayTimeInUs", delayTime));        easy_coroutine_usleep(delayTime);  // 退避等待    }}

复制代码

要点 7 ：使用 timed_wait 代替 wait

在典型的生产者消费者实现中，使用 timedwait 代替 wait，避免生产者未正确设置条件变量造成消费者卡死无法服务的窘境。

pthread_mutex_t mutex;pthread_cond_t  nonEmptyCondition;std::list<Task*> queue;void ConsumerLoop(){    pthread_mutex_lock(&mutex);    while (true)    {        while (queue.empty())        {            struct timespec ts;            ts.tv_sec = 1;            ts.tv_nsec = 0;            // 使用timewait            pthread_cond_timedwait(&nonEmptyCondition, &mutex, timespec);        }        Task* firstTask = queue.front();        queue.pop_front();        consume(firstTask);    }    pthread_mutex_unlock(&mutex);}

复制代码

要点 8：用协程代替异步回调

这是块存储 BlockServer 加载数据分片的代码；用异步回调方式难以实现这样的复杂控制逻辑，用协程却能轻松实现。

// load.cppStatus LoadTask::Execute(){    Status status;#define RUN_STEP(func) \    status = func();    if (!status.IsOk()) { ... }    // 串行执行下列步骤    RUN_STEP(doPrepareDirs);    ...... // 十几步    RUN_STEP(doTask);#undef RUN_STEP    ......}// files.cppStatus FileMap::SealFilesForLiveDevice(){    Status status = OK;    std::vector<SyncClosureR1<Status>*> sealDones;    STLDeleteElementsGuard<std::vector<SyncClosureR1<Status>*> >        donesDeleter(&sealDones);    // 并行 seal 每个文件    FOREACH(iter, mActiveFiles)    {        File* file = iter->second;        sealDones.push_back(new SyncClosureR1<Status>());        Closure* work = stone::NewClosure(                this,                &FileMap::doSealFileForLiveDevice,                file,                static_cast<BindCallbackR1<Status>*>(sealDones.back()));        InvokeCoroutineInCurrentThread(work);    }    // 收集结果    FOREACH(done, sealDones)    {        (*done)->Wait();        if (!(*done)->GetResult0().IsOk())        {            status = (*done)->GetResult0();        }    }    return status;}

复制代码

要点 9 ：在关键对象增加 magic 字段

这是块存储核心主路径的一段代码；在关键数据结构中增加 magic 字段和断言检查，能及时发现内存错误（例：内存踩坏）。

通常在下列两类结构增加 magic ：

1）关键的数据结构，如数据分片结构；

2）异步操作的上下文结构，如用户 IO Buffer 请求；

// stream.hclass Stream{public:    Stream();    ~Stream();    void Read(ReadArgs* args);    ......private:    // 增加 magic 字段    // 通常使用 uint32 或 uint64    uint64_t mObjectMagic;    ......};// stream.cpp// 定义 magic 常量// 常量值选择 hexdump 时能识别的字符串，以便在 gdb 查看 coredump 时快速识别// 此处使用 “STREAM” 的 ASCII 串static uint64_t STREAM_OBJECT_MAGIC = 0x4e4d474553564544LL; Stream::Stream()  : mObjectMagic(STREAM_OBJECT_MAGIC)  // 在构造函数中赋值{    ......}Stream::~Stream(){    // 在析构函数中检查并破坏 magic 字段，预防 double-free 错误    easy_assert(mObjectMagic == STREAM_OBJECT_MAGIC);    mObjectMagic = FREED_OBJECT_MAGIC;    ......}void DeviceSegment::Read(ReadArgs* args){    // 在重要的函数中检查 magic 字段，预防 use-after-free 错误    easy_assert(mObjectMagic == DEVICE_SEGMENT_OBJECT_MAGIC);    ......  }

复制代码

要点 10 ：SanityCheck() 合法性检查

这是块存储核心模块的一段代码 StreamWriter 负责管理正在写入的 Stream，它为每个写请求选择合适的 Stream 写入，并处理文件满、写失败等异常情形；曾在线下测试发现由于未添加合法性检查，导致内存踩坏的 meta 错误数据持久化到磁盘中，在数据分片发生迁移时，从磁盘加载错误的 meta 数据持续夯死，不可恢复。在重要操作前后及定时器中检查数据结构中的重要的不变式假设，这样尽早发现代码 bug 在重要的操作前后或是在定时器中执行检查。

class StreamWriter{public:    ......private:    struct StreamGroup    {        WriteAttemptList failureQueue;        WriteAttemptList inflightQueue;        WriteAttemptList pendingQueue;        uint64_t         commitSeq;        uint64_t         lastSeq;    };    uint32_t     mStreamGroupCount;    StreamGroup  mStreamGroups[STREAM_GROUP_COUNT];        ......};void StreamWriter::sanityCheck(){#ifndef NDEBUG  // expensive checks    for (uint32_t i = 0; i < mStreamGroupCount; i++)    {        // Check that sequence in "failureQueue", "inflightQueue" and "pendingQueue" are ordered.        const StreamGroup* group = &mStreamGroups[i];        uint64_t prevSeq = group->commitSeq;        const WriteAttemptList* queues[] = {            &group->failureQueue,            &group->inflightQueue,            &group->pendingQueue        };        for (size_t k = 0; k < easy_count_of(queues); k++)        {            FOREACH(iter, *queues[k])            {                const WriteRequest* write = iter->write;                PANGU_ASSERT(prevSeq <= write->seq); // SanityCheck                prevSeq = write->seq + write->lbaRange.rangeSize;            }        }        ASSERT(prevSeq == group->lastSeq); // SanityCheck    }    ......#endif  // NDEBUG}

复制代码

要点 11 ：用告警代替进程崩溃

这是块存储核心路径的一段代码，在加载数据分片时通过交叉校验对数据正确性进行合法性检查，遇到严重错误时发起电话告警，以此代替 assert，避免生产集群大规模故障时，数据分片持续调度造成整个集群进程 Crash 的级联故障。

在多租户系统中，单租户出现严重问题不应影响其他租户的服务。

在块存储，我们仅允许检查对象 magic 和线程是否正确的断言。其它断言由告警代替。

Status LoadTask::doTailScanFiles(){    ......    for (id = FIRST_REAL_FILE_ID; id < mFileSet->GetTotalFileCount(); id++)    {        File* file = mDiskFileSet->GetFile(id);        if (file->GetLogicalLength() < logicalLengthInIndex)        {             const char* msg = “BUG!! Found a data on disk with shorter length ”                               “than in map. This is probably caused by length reduction of ”                               “that file.”;   // 记录详细的日志，包括文件名、期望长度、实际长度等             PGLOG_FATAL(sLogger, (__FUNCTION__, msg)                         (“Stream”, mStream->GetName())                         (“File”, file->GetFileName())                         (“FileId”, file->GetFileId())                         (“FileLengthOnDisk”, file->GetFileLength())                         (“FileLengthInIndex”, physicalLengthInIndex)                         (“LogicalLengthOnDisk”, file->GetLogicalLength())                         (“LogicalLengthInIndex”, logicalLengthInIndex)                         (“MissingSize”, physicalLengthInIndex - file->GetFileLength()));             SERVICE_ADD_COUNTER(“LSM:CriticalIssueCount”, 1);  // 触发电话告警             return LSM_FILE_CORRUPTED;        }    }}

复制代码

要点 12 ：时间溢出之一

我们当前使用的内核配置 HZ=1000，jiffies 变量每 49 天溢出，Linux 将 jiffies 变量初始值设置为负数，使系统启动后 5 分钟发生第一次溢出；让这段容易出错的危险代码每天都被执行到，这些再也不用担心出现黑天鹅事件了。

linux/include/linux/jiffies.h/*•* Have the 32 bit jiffies value wrap 5 minutes after boot* so jiffies wrap bugs show up earlier.*/#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))/** These inlines deal with timer wrapping correctlyYou are•* strongly encouraged to use them* 1. Because people otherwise forget* 2. Because if the timer wrap changes in future you won't have to* alter your driver code.** time_after(a,b) returns true if the time a is after time b.*/#define time_after(a,b) \    (typecheck(unsigned long, a) && \    typecheck(unsigned long, b) && \    ((long)((b) - (a)) < 0))

复制代码

要点 13 ：时间溢出之二

习惯上代码中以微秒表示时间， int32 能表示的最大时间仅为 2147 秒，约 35 分钟，容易溢出；历史上块存储值班同学在处理另一个 P4 故障时，为缓解分布式集群中心管控节点压力，临时调整 flag 增加调用中心管控节点 RPC 的调用间隔。新的 flag 在运行时产生 int32 整型溢出，进程崩溃，引起整个集群级联故障，服务中断造成 P1 生产故障；血淋淋的教训：总是用 int64/uint64 表示时间。

要点 14 ：避免有歧义的函数名和参数表

这是 libeasy 的一段代码，这是基于时间轮实现的定时器，用来代替 libev timer；函数名和参数表要符合直觉，大多数使用者没空读你的注释，小部分使用者读了你的注释也看不明白。

// easy/src/io/easy_timer.h// ----------------------------------------------------------------------------------// following interface, use easy_timer_sched from th(io thread or worker thread),// ** DON NOT support async call **//int easy_timer_start_on_th(easy_baseth_t *th, easy_timer_t *timer);int easy_timer_stop_on_th(easy_baseth_t *th, easy_timer_t *timer);

复制代码

1.2 测试

测试代码其实是产品代码的“用户”，写测试代码前考虑如何“使用”产品；好的测试是 what，包含 given when then；差的测试是 how，每次方法更改时都必须完全重写测试，或许需要重新考虑系统本身的体系结构。

图 2 测试原则、可测性

要点 1 ：边界测试

以下是块存储两个历史生产 Bug；关注上下限，边界条件最易出错。

TEST_F(..., SharedDisk_StopOneBs)(...) {    BenchMarkStart(mOption);    // for循环反复注入    mCluster->StopServer(0);    mCluster->StartServer(0);    // 修复前无第12行无代码，无下限检查，全部失败时Case PASS    // 共享盘开盘后线程死锁必IO Hang，有测试无断言遗漏Bug导致P1故障    EXPECT_GT(mIoBench->GetLastPrintIops(), 0);    EXPECT_GT(mIoBench->GetMaxLatency(), 0);    // 断言检查，边界上限    EXPECT_GT(20 * 1000000, mIoBench->GetMaxLatency());    // Do something below}Status PRConfig::Register )(...){     assertIoThread();     // 修复前缺少=，导致Sever Crash     if (unlikely(mRegistrants.size() >= MAX_REGISTRANT_NUM))    {        LOG_ERROR(...);        return SC_RESERVATION_CONFLICT;    }    // Do something below}

复制代码

要点 2 ：状态/分支测试

以下是块存储两个历史生产 Bug；状态流程图，影响数据正确性和服务可用性的关键路径、异常分支、状态组合需测试覆盖。

void WalStreamWriterPool::tryCreateWalWriter(){    AssertCoroutine();    ASSERT_DEBUG(mIsCreating);    Status status = OK;    while (...)    {        WalStreamWriter *writer = mWalManager->CreateWalWriter();        status = writer->Open();        // 修复前无第14行代码部分，未处理Commit，失败导致丢掉WAL文件，进而丢数据        if (status.IsOk())        {            status = mWalManager->Commit();        }        // Do something below}void RPCController::StartCancel(){    if (_session) {        if (_pendingRpc != NULL) {            // 修复前无第29行代码，线程Hang进而IOHang            // 未测试覆盖call StartCancel  before handshake            _session->need_cancel = true;        } else {            easy_session_cancel(_session);        }    } else {        easy_error_log(...);    }}

复制代码

要点 3 ：重复/幂等性测试

以下是块存储两个历史生产 Bug；第一个如下图所示，未释放内存，长时间运行造成内存泄漏；第二个是 19 年遇到的一个问题，BM 在处理 open device 时没处理好幂等问题，导致磁盘 open 成功后仍然 I/O hang ；有一些问题只有经过长时间的重复测试才能发现，关注代码中每一次重试，敏感接口的 API 幂等性需测试覆盖。

Status CompressOffsetTable::Seal(){    // Do something before    status = mTableFile->Seal();    if (!status.IsOk())    {        PGLOG_ERROR(...);        return status;    }    mIsSealed = true;    // 修复前无第14行代码，文件写入已完成，清空缓存，释放内存    mEasyPool.reset();    // Do something below}

复制代码

要点 4 ：兼容性测试

兼容性包含：协议兼容性、API 兼容性、版本升级兼容性、数据格式兼容性；对于所有依赖的兼容性假设需通过测试自动化覆盖，兼容性问题是很难测试覆盖并且问题高发的部分，兼容性问题应该在设计阶段、编码阶段提前预防，避免兼容性问题，而非寄希望于兼容性测试来兜底。

void ActiveManager::SubmitIO({     // 【版本兼容性】 SDK 和 Server线程不对齐，旧版本SDK不支持切线程     if (UNLIKELY(GetCurrentThread() != serverThread))     PGLOG_WARNING(...  "Server thread mismatch");     response->ErrorCode = SERVER_BUSY;     done->Run();}void ChunkListAccessor::SetChunkInfoAndLocations(){    uint8_t flags = mFileNodePtr->fileFlags;    bool isLogFile = IsFlatLogFile(flags);    ASSERT(        //【协议兼容性】Master 和 SDK异常场景定长误判        (isLogFile && vecChunkInfoNode[0].version <= masterChunkInfo.version) ||        !isLogFile);         // Do something below}// 【API兼容性】 Server 和 Master的错误码不一致，数据分片反复加载/卸载// Master侧，device_load.cpp// if(status.Code() == LSM_SEGMENT_EXIST_OTHER_VERSION))// Server侧，device_load.cpp// return LSM_NOT_OWN_SEGMENT;

复制代码

要点 5 ：防御性测试

系统服务上限的边界是多少？客户端无退避重试、突发大流量等造成的故障数不胜数，关注系统在最差情况下的表现，明确系统的能力边界，对系统服务边界的数学模型进行理论分析和实验验证，通过极限压测验证系统最大可服务能力符合设计预期，推荐参考接近不可接受的负载边界 [01]。

要点 6 ：避免写出不稳定 Case

Case 不稳定真是一个让人头大问题，总结了一些不稳定的测试常见原因，希望大家记住并知行合一。

测试不聚焦，无脑复制粘贴，等价类测试爆炸
异步等待，基于时间假设，sleep 并发，未能在预期的窗口期交互
有顺序依赖的测试，共享某个状态
资源溢出，数据库链接满、内存 OOM 析构随机 core
析构未严格保序或者未构造
多线程共享资源的错误用法导致概率 crash
有未处理完的任务就退出

TEST_F(FastPathSmokeTestFixture, Resize){    // ... Do something    ResizeVolume(uri, DEVICE_SIZE * 2);    Status status = OK;    do {        // 状态依赖，未检查resize 是否成功，导致错误的认为是越界io处理        status = Write(handle, wbuf.get(), 0, 4096);        if (status.Code() == OK)        {            break;        }        easy_coroutine_usleep(100*1000);    } while(1);    // ... Do something}// volume_iov_split_test.cppTEST(VolumeIovSplitTest, Iovsplit_Random){    // ... Do something    size_t totalLength = 0;    // 修改前无+1，0是非法随机值，造成Case低概率失败    totalLength = rand() % (10*1024*1024) + 1    // ... Do something}

复制代码

二、本地工具

2.1 Docker 单机集群

对于分布式系统，能够在开发机上自测端到端的跨模块/跨集群的功能测试，极大的提高测试效率和开发幸福感。在开发调试期间，Docker 集群用完即抛，拥有属于自己的无污染的“一手”功能测试集群，代码主路径必现的进程 Crash 均可在开发阶段发现。Docker 使用极少的系统资源，有效地将不同容器互相隔离，快速创建分布式应用程序，非常适合集群测试使用。

块存储在没有 Docker 单机集群之前，测试集群级功能测试至少需要 12 台物理机，我们通过将块存储、盘古和女娲的服务装进容器中，实现单机 OneBox，在开发机上（物理机 /虚拟机/Docker/Mac 均可，无 OS 依赖），一键秒级部署和销毁一个集群，基于 Docker 单机集群实现 Docker Funtion Test，沿用单元测试的 gtest，上手门槛低，极大的提高了测试效率和开发幸福感，Docker Funtion Test 是在代码门禁中运行，即代码提交入库之前自动触发测试，在代码入库之前，百分之百拦截必现的进程 Crash 问题。

图 3 块存储 Docker 单机集群

2.2 本地出包自助 E2E

研发效能低下的团队的一个典型表现，质量强依赖全链路端到端（End-To-End，简称 E2E），测试环境维护成本极高，常常因为环境污染导致无效测试，是否能够将全链路 E2E 测试实现白屏化，告别环境修复？

在开发期间调试，不可避免有大 Size 的 Patch 修改，代码门禁 Unit Test / Smoke Test / Funition Test 仅覆盖功能测试，涉及到 IO 性能、运维、用户态文件系统、用户态网络协议的代码逻辑修改，无法在代码门禁覆盖。面对这个问题，块存储开发者可以在开发机编译出包，测试平台白屏自助验证 E2E 测试，操作共 3 个步骤：编译上传包 → 提交测试任务 → 查看测试结果。降低测试门槛可以有效的提高测试的主观能动性，进而提高测试运行频次，当测试不再是负担的时候，大家更愿意做测试，谁会拒绝投资少收益高的事呢？

图 4 测试平台自助 E2E

三、单元测试

3.1 编写测试样例

对于块存储主仓库，增量代码覆盖率当前强制卡点 85%，生产代码与测试代码需要同步原子提交，否则将因覆盖率不足阻塞提交，这也倒逼了大家养成测试左移的工作习惯，编写 Unit Test / Smoke Test / Funition Test 是块存储每位开发者提交代码的必备技能，团队同学柏亿曾讲过一句话，“如果我写了代码而没有加自动化 Case，就相当于我做了一件华丽的衣服，又丢到了垃圾桶里，弃如敝履 ”，通过自动化门禁测试来保证系统设计、代码实现不被后续修改 Break，降低系统质量风险，依赖假设足以保证，更多 Good/Bad Case 可以参考《Software Engineering at Google》的 “单元测试”章节 [02]。

图 5 EBS UT/ST/FT

3.2 代码门禁说明

代码门禁（简称 CI）即代码提交之前自动运行的测试，测试全量通过后方可提交，类似于函数计算，Test as a Service。代码门禁是测试左移 [03] 的必备单品。块存储 CI 门禁基于 Google 开源云原生 CI 框架 Tekton 实现，支持分布式编译和分布式测试，Kubernetes 门禁集群中的 Cpu、Mem、Disk 资源限制 Limit，每个 Case 独占容器，仅 Cpu 超卖，相当于模拟主频降频，增加了发现 bug 的概率，曾多次触发大量低概率时序 bug；代码门禁包含编译构建、单元测试、冒烟测试、功能测试、代码风格检查、静态代码扫描、增量代码覆盖率卡点等检查项。在推广测试左移的近三年，块存储门禁 Case 数量逐年翻倍。

图 6 块存储代码门禁

四、Code Review

预防胜于治疗，研究表明高效的 Code Review 可以发现 70-90%的 bug，Review 作用如下：

提高团队代码标准，所有人共享同一套标准，阻止破窗效应；
推动团队合作 reviewer 和 submitter 可能有不同的视角，主观的观点经常发生碰撞，促进相互学习；
激励提交者，因为知道代码需要别人 review，所以提交者会倾向提升自己的代码质量。大部分程序员会因为同事对其代码显示出的专业性而感到自豪；
分享知识 submitter 可能使用了一种新技术或者算法，使 reviewer 受益。reviewer 也可能掌握某些知识，帮助改进这次提交；

图 7 Code Review 可以发现 70-90%的 bug

对于 Submitter 和 Reviewer 的共同建议，开放的心态，良好的互动，Submitter 给到 reviewer 更多的输入后，有益于问题的挖掘。

图 8 一个 Review 互动的优秀案例

4.1 For Submitter

要点 1 ：For Submitter - 一次提交不要超过 400 行代码

研究表明 [04]：在一次 CR 中，Reviewer 应一次至多处理 200 至 400 行代码(lines of code)。若超过 400 行，人的大脑无法有效的处理，发现缺陷的能力将下降。在实践中，使用 60-90 分钟来 review 一个 200-400 行的 patch，应该能发现 70-90%的缺陷。即如果这个 patch 里面存在 10 个 bug，那么在 CR 阶段应该能发现 7 至 9 个。

图 9 缺陷密度 vs 代码行数

要点 2 ：For Submitter - 做自己的第一个 reviewer

自己的狗粮自己先吃，自我 Review 有以下几个注意事项：

端正心态，reviewer 是帮你发现问题的人，而不是阻塞你提交的人；
认真对待 description，降低 Reviewer 的理解成本；
一次提交只解决一个问题，降低 review 的复杂度；
如果需要做重大修改，写找 reviewer 对齐大致的修改范围，再开始写代码，避免越行越远；

图 10 Code Review 一个 Description 的优秀案例

4.2 For Reviewer

要点 1 ：For Reviewer - 控制 review 速度

研究表明 [04]：当 Reviewer 以超过 500 行/小时的速度 review 代码时，缺陷的发现率会有显著的下降。建议 Reviewer 控制好自己的速度，保障好 review 质量。建议一次 review 的时间不要超过一小时，当任务多时建议提高 review 的频率，避免持续过长时间。

图 11 缺陷密度 vs 检查速度

要点 2 ：For Reviewer - Review 的重心

我们不可避免的需要 review 一些较大的 patch， Review 的顺序：接口 > 测试 > 实现，reviewer 可以假设自己是该代码的使用方，该接口的定义及行为是否符合自己的预期？如果没有时间，至少也应该看一遍接口定义， 测试代码的质量与实现的质量同等重要，不可敷衍，理解提交者想通过测试测哪些东西比理解测试代码的含义更重要。

要点 3 ：For Reviewer - Tips

给建议，更要给原因，帮助提交者进步；
如果看到写得好的代码，不要吝啬赞赏的语句，提交者真的会很受鼓舞；
对于看不明白的地方一定要提出问题，而不是轻易放过；
不要花过多力气去理解难以理解的代码，如果一眼看不明白，第二眼还看不明白，说明这块代码需要改，很大可能过一段时间提交者也会看不明白；
如果 patch 太大，应建议提交者分拆；
慎重审查 .h 以及协议的修改；
没有测试覆盖的代码没必要去看。

五、分支管理

5.1 主干开发

列宁：帝国主义是资本主义的最高阶段
南门：主干开发（trunk based development）是持续集成（continuous integration）的最高阶段

在开发模式上，块存储学习了微软、Google 的大库主干开发方式，过去多分支开发初期并行迭代，开发周期宽松，但多分支开发很容易漏提交，块存储也曾因漏提交 bugfix 导致一起 P1S1 故障，多分支合并冲突多、迭代慢，需要长期占用多套测试环境，有限的测试资源回归频次相对少。块存储所有持续集成测试资源均集中在主干分支回归，“集中力量办大事”。

主干开发对开发者提出了很高的要求，不仅要具备有功能特性拆分的能力，而且需要确保每一次代码提交，都能够达到准上线的质量标准，这也倒闭了测试左移的编码习惯，在提交代码入库之前进行测试编码。

图 12 块存储主干开发

5.2 主干/分支发布

发布模式分两种，公有云是主干分支发布，专有云是 LTS（Long Time Support）拉 Release 分支发布（专有云发布节奏需 follow 客户要求，公有云发布节奏自主可控）。主干发布，既不是目的，也不是手段。主干发布是结果，是测试能力不断提升后水到渠成的结果，块存储持续集成交付详见下文第八章。切勿为了主干发布而主干发布，严格控制发布变量和发布节奏，避免为了修复一个 bug，引入了另一个更严重的 bug，只有经过成熟的测试验证方可进行发布，欲速则不达，敬畏生产。

六、测试 & 环境

6.1 测试脚手架

除了代码门禁的功能 Case 覆盖之外，Feature Owner 需要补充代码后置全链路测试 E2E 和 BVT Case，大版本发布需要经过大规模故障演练的验证方可发布上线，UT/ST/FT 每月回归三千多轮，对于信用分低的 Case（即不稳定 Case）运行轮数权重翻五倍，即每月运行上万轮，通过高频测试尽量多暴露各层面的不稳定因素，倒逼人肉环节的自动化。块存储按照不同的场景提供了多种测试脚手架进行测分级，越轻量的测试回归轮数越多，更多详细说明如下图所示。

图 13 块存储测试分级

6.2 环境标准化

对于测试环境的标准化，采用两个思路：云原生用完即抛、资源池化集中管理。

云原生隔离用完即抛，分三种：Docker FT、门禁、K8S E2E。Docker FT 在 2.1 章节有详细介绍；门禁 Kubernetes 集群对开发者无感知，在 3.2 章节有详细介绍；K8S E2E 集群在 6.1 章节的表格中有使用说明介绍，不同于 Docker FT，支持用户态网络协议，支持运维和监控平台等，3 台物理机即可模拟 12~24 台虚拟集群，如集群环境污染，可半小时销毁重建，而非人肉修环境。

测试资源在测试平台集中管理，分两种：白屏测试只读环境、黑屏测试读写环境，尽量提升资源池化比例。第一种，白屏测试包含三部分：代码门禁 CI 集群、CD E2E 每日回归环境、长时间稳定性预发环境；环境隔离只读，从而杜绝破坏宿主机、修改配置、残留进程等污染环境行为。第二种，黑屏测试即读写环境，用于开发测试联调，采用集群健康度检查工具提前发现环境污染，覆盖网络、磁盘、OS 等几十个检查项，避免测试过程中反复踩坑带来的无效重复测试，如下图所示。

图 14 块存储集群健康度检查

七、缺陷管理

为什么要进行缺陷管理？由于 Bug 信息不对称，难追溯，开发和发布时间异步，fullmesh 协同交互成本极高，且可靠性很难保证，在《人月神话》书中描述， , 组织规模人数, 沟通协同成本，指数增加。5.1 小节中描述的 P1S1 故障发生后，团队进行了 hotfix 重发，消除生产风险，但由于对 Bug 影响集群范围疏忽，导致一个月后同样的故障重复发生，造成二次伤害，吸取教训，团队通过开发 git-poison，实现 bug 分布式源码管理，支持追溯、查询和反馈，自动化 bug 发布卡点、精准召回 bug 中毒版本，避免 bugfix 漏发，降低人因失误造成的质量风险。

7.1 git-poison 投毒

基于 go-git 实现 git-poison：简单易用的 bug/bugfix 追溯工具，git 作为分布式版本管理工具友好地支持了多人并发的一致性问题，简单可靠，开发同学只需要记住一件事：任何时候发现有 bad bug，要 block 预发/生产发布的，抓紧投毒！可复制性高，无论是“分支开发、主干发布“，还是”主干开发、分支发布“，均适用；不依赖于人和人之间的沟通协调，人的 involve 越少，出错的机会越小。

图 15 git-poison 投毒/解药/银针

7.2 poison 发布阻塞

开发机代码仓库是 poison 的唯一数据生产源，测试平台和发布平台消费 poison 数据，实现 PoisonCommit 发布阻塞机制，测试平台在填写 ReleaseNote 一键导入 Bug/Bugfix，评估本次版本发布的质量风险，在发布平台通过“集群-模版-Bug-版本”四维度画像实现 Bug 追溯和查询，精准定位 Bug 中毒域，召回 Bug 版本。

图 16 “集群-模版-Bug-版本” 四维度生产画像

八、持续交付

8.1 从开发到上线

在代码从开发到上线的整个生命周期存在四阶段系统强制卡点，致力于“从不做错到做不错”。自动化的价值不仅仅是节约时间，更是提高交付质量和交付效率，降低交付成本（例：工作状态上下文切换、完成一项任务的认知负荷、重复工作量）。

质量防控首先在源头处，通过代码门禁及时发现；持续集成，每日主干回归，缩短反馈弧，一有问题，马上定位修复。

图 17 块存储从开发到上线

8.2 分模块发布

代码库存越是积攒，就越得不到生产校验，积压越多，代码间交叉感染的概率越大，下个 Release 的复杂度和风险越高，流水不腐，户枢不蠹。那么，如何提高 Code Velocity? 除了持续集成建设外，发布阶段也需要解除强绑定，学习微服务化的思路，实现分模块发布，通过将发布模版以模块粒度拆分，各自模块仅拥有自己模块的权限，大幅提升了权限安全管理和发布的灵活性；从发布方面解决了“大锅饭”的问题，真正的将组织层面质量责任落实到了每一个模块的 Owner 上。

通过微服务化，将单次版本百人协同的成本降低到十人以下，彻底告别“发大车”，各自聚焦，各行其道，互不干扰。

图 18 块存储分模块发布

分模块发布后，由于各模块的发布频次和周期不同，你追我赶，超车频繁，也带来了版本兼容性的挑战，原本设计正交的功能常常出现意想不到的兼容性 Bug，块存储在实行分模块发布后屡次踩坑兼容性生产问题，其中包括一次 P1 故障。面对分模块发布带来的兼容性挑战，一方面，单个服务内，线上版本分裂多，通过收敛治理，全网拉齐；另一方面，多个服务间，笛卡尔积的版本组合多，测试如何覆盖不同服务不同版本的组合，昂贵的测试成本和漫长的测试时间是无法接受的，如前文所述，采用云原生的思路，通过轻量化 Docker 集群降低测试成本，同时提高测试效率。

图 19 分模块发布后兼容性测试

九、文化实践

9.1 效率工具和方法

开发工具

工欲善其事，必先利其器。工具没有好与坏，要看你如何使用，一个高效的工具事半功倍，推荐一些日常工具：

开发机：窗口操作使用 Screen、tmux 保持链接不中断、 SSH 远端包括 iTerm2、Bash、Zsh、Fish、编辑器包括 VSCode、Vim 、调查问题 Debug 使用 gdb、pdb、内存泄漏：tcmalloc、代码扫描静态 cppcheck 和动态代码扫描 asan；
Linux：Cpu/Mem 资源查看使用 tsar --mem/cpu/io/net -n 1 -i 1、top 等、网络使用 lsof、netstat、磁盘使用 iostat、block_dump、inotifywait、df/du、内核日志包括/var/log/messages、sudo dmesg、性能工具 strace、perf，IO 压测 FIO；
文档类：语雀的在线 UML 图/流程图/里程碑方便多人共同编辑等、Teambition 的项目管理甘特图、 Aone 的需求管理和缺陷管理、离线工具诸如 Xmind 思维导图/draw.io 流程图/OneNote。

工作方法

良好的工作方法，可以让自己的成长速度形成复利，推荐阅读两本书《直击本质》和《系统之美》，或许你可以从书中找到不同人成长速率差异的答案，这里推荐三个工作方法：

SMART 原则，适用场景：OKR、KPI、绩效自评

S：Specific，具体的
M：Measurable，可以衡量的
A：Attainable，可以达到的
R：Relevant，具有一定的相关性
T：Time-bound，有明确的截止期限

论文学习方法，推荐先阅读大数据经典系列（例如 Google 新/老三驾马车），对于存储领域同学，推荐 Fast 论文

Motivation: 解决了一个什么样的问题？为什么要做这个问题
Trade-off: 优势和劣势是什么？带来了哪些挑战？
适用场景: 没有任何技术是普适的，业务场景，技术场景
系统实现: 组成部分和关键实现，核心思想和核心组件，灵魂在哪里？
底层原理: 其底层的关键基础技术，基于这个基础还有哪些工作？
Related Works: 这个问题上还有什么其他的工作？相关系统对比？不同的实现、不同的侧重、不同的思路？

TDD，Test-diven Development 测试驱动开发，团队石超推荐，“自从看了 TDD 这本书，我就爱上了写 UT”，当时听完这句话驱动了我的好奇心，TDD 到底一个什么神奇的方法？后来发现在《软件测试》《Google ：Building Secure & Reliable Systems》《重构》《重构与模式》《敏捷软件开发》《程序员的职业素养》……国外泰斗级程序员大叔的书里，全部都推荐了 TDD。TDD 不是万能药，主要思维模式是，先想清楚系统的行为表现，再下手编码，测试想清楚了，开发的 API/系统表现就清晰了，API/函数/方法语义就明确了。

9.2 个人成长和踩坑

身份从学生到工程师，必然伴随着成长的阵痛感。在工程实践方面，不再是学生时代的实验课题或者编程比赛，而是从程序到编程系统产品的转变，程序员的工作不止是编程，是把想法变成产品能力的过程。从程序到编程系统，研发成本翻 3 倍，包括接口设计和集成测试；从程序到编程产品，研发成本翻 3 倍，包括通用化、测试、文档、维护；而从从程序到编程系统产品，研发成本翻 9 倍，日常编码时间占比 20%～30%，如若你感觉编码时间占比过少，或许是学生思维的惯性，块存储团队践行 DevOps，无专职测试岗和运维岗，对于每一位 Feature Owner 而言，需要独立负责该 Feature 的 “开发 → 测试→ 发布→巡检” 全生命周期。

图 20 来源《人月神话》编程系统产品的演进

个人成长

持续优秀，自我迭代，再牛逼也只是一时的，很牛逼的人能把自己当代码迭代，一个版本一个版本演进，不停 loop 起来，有针对性、上升式的学习和实践。夯实最基础的底层知识，融会贯通的人都是有底层逻辑的，多阅读经典。分享三条 Facebook 研发效能负责人推荐的高效工作方法：

抽象和分而治之

抽象，明确模块之间的依赖关系，确定 API 接口
分而治之，对子系统设计进行合理的注释，帮助代码阅读者对软件结构有更直观的了解
代码提交尽量做到原子，即不可分割的特性、修复或者优化，测试代码同生产代码同一个 patch 提交

DRY（Don’t Repeat Yourself)

寻找重复的逻辑和代码，对重复内容进行抽象和封装
寻找流程的重复，使用脚本或者工具自动化，通过自动化提高交付质量和效率，降低交付成本
沉淀踩坑经验到自动化工具和平台中，独乐乐不如众乐乐，避免不同人踩相同的坑，降低无效时间开销

快速迭代

Done is better than prefect，不要过度设计
尽快让代码运行和快速验证，不断迭代来完善
为了能够快速验证，本地测试成本低，缩短反馈弧
实现一个可以运行起来的脚手架，再持续添加内容

踩坑心得

总结了以下三条过往工作中踩坑建议：

忌“太心急”，慢即是快

需求澄清：类似 TCP 三次握手，用自己理解的方式再给对方讲一遍，确认双方理解一致，对焦，避免重复返工
自我提问：为什么做这件事？业务价值是什么？关键技术是什么？已有的系统和它对比有什么不同？兄弟团队是否做过类似的工作？是否有经验可供参考？业务/技术的适用场景是什么？预计耗时和进度风险？
新人往往脚踏实地，忘记了仰望星空，只顾着埋头苦干，不思考背后的业务价值，这一锄头，那一铁锹，遍地都是坑，就是不开花，费时费力，成就感低。

忌低效沟通，用数据说话

精确地描述问题，上下文和范围，提供有效信息
文档是提高沟通效率的最佳方式之一，Google 有文档文化，推荐阅读《Design Docs at Google》[05]
Bad Case：「测试 CX6 网卡时，IOPS 大幅下降」
Good Case：「在 100g 网络标卡 CX6 验证性能时，8 jobs 32 depth iosize 4K 场景下，极限 IOPS 从 120 万下降至 110 万，与 FIC 卡相比性能存在 8%差异」

忌“蠢问题”，学会提问

鼓励新人多提问，但提问的问题一定要有质量
关于如何提出一个好问题推荐阅读《提问的智慧》[06]
Bad Case：「我在编译耗时很长，我怀疑是资源不够，这种情况怎么办？」
Good Case：「我的开发机编译耗时 2 小时，不符合预期，OS 是 centOS 7U、128GB 内存、64Core，编译并发度是 20 核，未限制内存，编译过程使用 Top 查看确实 20 核并发，Cpu 和 Mem 没有达到瓶颈，iostat 看磁盘使用率每秒 60%」

十、延伸阅读

文章的最后，推荐几本最近阅读过的书，好书读得越多越让人感到无知，“流水不争先，争得是滔滔不绝”，找到适合自己的节奏学习。

《编写可读代码的艺术》，豆瓣评分 8.7，推荐理由：漂亮的代码长什么样、命名变量避免歧义、写出言简意赅的注释、抽取小函数让测试用例更易读等。
《Software Engineer at Google》，豆瓣评分 8.7，推荐理由：介绍 Google 软件工程文化、流程、工具，github 有中文电子版。
《人月神话》，豆瓣评分 9.2，推荐理由：被誉为软件工程圣经，与《人件》共同被称为双子星，两者是软件行业的神书，而其他书只能被称为经典，自 1986 年出版至今，每年销售量上万本，值得每隔 1～2 年反复阅读，初看不知剧中意，再看已是剧中人。
《数据密集型应用系统设计》，豆瓣评分 9.7，推荐理由：软件开发者的必读书籍，衔接理论与实践，包括数据密集型应用系统所需的若干基本原则、深入探索分布式系统内部机制和运用这些技术、解析一致性/扩展性/容错和复杂度之间的权衡利弊、介绍分布式系统研究的最新进展（数据库）、揭示主流在线服务的基本架构等。

参考阅读

[01] 接近不可接受的负载边界

https://www.usenix.org/conference/srecon18americas/presentation/schwartz

[02] Software Engineering at Google

https://qiangmzsx.github.io/Software-Engineering-at-Google/#/zh-cn/Chapter-12_Unit_Testing/Chapter-12_Unit_Testing

[03] 测试左移在大型分布式系统中的工程实践

https://mp.weixin.qq.com/s/DSsscC_5ldOTCTbW6u-ubw

[04] Best Practices for Code Review

https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

[05] Design Docs at Google

https://www.industrialempathy.com/posts/design-docs-at-google/

[06] 提问的智慧

https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md

发布于: 2022-10-11阅读数: 108

原文链接:【http://xie.infoq.cn/article/d314795d0c7b192977ded9cc1】。文章转载请联系作者。

阿里技术

关注

专注分享阿里技术的丰富实践和前沿创新。 2022-05-24 加入

阿里技术的官方号，专注分享阿里技术的丰富实践、前沿洞察、技术创新、技术人成长经验。阿里技术，与技术人一起创造成长与成就。

发布

暂无评论

创作场景

阿里云块存储团队卓越工程实践

一、编码习惯

1.1 开发

要点 1 ：语义简单明确

要点 2 ：简洁 ≠ 代码短

要点 3 ：提前返错

要点 4 ：利用析构函数做清理工作

要点 5 ：用朴素直观的算法

要点 6 ：用轮循代替条件变量

要点 7 ：使用 timed_wait 代替 wait

要点 8：用协程代替异步回调

要点 9 ：在关键对象增加 magic 字段

要点 10 ：SanityCheck() 合法性检查

要点 11 ：用告警代替进程崩溃

要点 12 ：时间溢出之一

要点 13 ：时间溢出之二

要点 14 ：避免有歧义的函数名和参数表

1.2 测试

要点 1 ：边界测试

要点 2 ：状态/分支测试

要点 3 ：重复/幂等性测试

要点 4 ：兼容性测试

要点 5 ：防御性测试

要点 6 ：避免写出不稳定 Case

二、本地工具

2.1 Docker 单机集群

2.2 本地出包自助 E2E

三、单元测试

3.1 编写测试样例

​3.2 代码门禁说明

四、Code Review

4.1 For Submitter

要点 1 ：For Submitter - 一次提交不要超过 400 行代码

要点 2 ：For Submitter - 做自己的第一个 reviewer

4.2 For Reviewer

要点 1 ：For Reviewer - 控制 review 速度

要点 2 ：For Reviewer - Review 的重心

要点 3 ：For Reviewer - Tips

五、分支管理

5.1 主干开发

5.2 主干/分支发布

六、测试 & 环境

6.1 测试脚手架

6.2 环境标准化

七、缺陷管理

7.1 git-poison 投毒

7.2 poison 发布阻塞

八、持续交付

8.1 从开发到上线

8.2 分模块发布

九、文化实践

9.1 效率工具和方法

开发工具

工作方法

9.2 个人成长和踩坑

个人成长

踩坑心得

十、延伸阅读

参考阅读

阿里技术

评论

3.2 代码门禁说明