Chief Operating Officer / China
Running halls that are never allowed to stop
A data hall's real capacity is whatever it can still carry after one piece of its equipment has failed.
01
Hall capacity defined after the first failure
Every hall at Haolinjiang has a written capacity statement setting out the IT load it can carry with its designed redundancy intact: one UPS module, one chiller and one precision cooling unit out of service, and the generators carrying the site after a grid loss. Sales can offer only what that statement allows. I review any request to exceed it personally, and the answer is usually space in another hall rather than borrowing from the redundancy of an existing one. Statements are revised after every significant change, including battery replacements and the arrival of high-density cabinets, which can concentrate heat in a way an average kilowatt figure hides. Customers receive a summary of the redundancy their hall provides. That makes our commitments easier to compare and harder for anyone, including me, to relax under commercial pressure.
02
Energy approvals treated as operating commitments
A new building's energy-conservation review fixes expectations about its efficiency and annual consumption. I keep those figures in the monthly operating report beside availability and revenue, because a building that drifts above its approved efficiency can weaken our next application and invite questions from provincial authorities. The practical work is mostly unglamorous: supply-air temperatures agreed with customers, containment that is genuinely closed, chiller and pump sequences tuned for partial load, and metering accurate enough to separate our losses from customer consumption. Partial load is where many efficient designs disappoint, so I report PUE by hall and by load band rather than as one estate average. Where a customer wants colder air than its hall was designed to supply, we discuss the energy cost openly and price it instead of absorbing it quietly.
03
Building new halls beside live ones
Most of our construction happens on campuses that are already serving customers. A contractor cutting into a shared cable tray or isolating a common water loop can affect a live hall as easily as a new one. I require a single interface register for every project, listing each point where new work touches existing systems, the owner on each side and the agreed isolation method. No new hall accepts customer equipment until it has passed integrated systems testing at full simulated load with load banks, including a grid loss and generator start. I would rather pay for an extra week of testing than discover a sequencing fault with customers inside. I also hire and train the shift team for a new building at least three months before opening, so that the people who will run it have watched it being tested.
04
Shift operations that keep judgement consistent through the night
Our 252 shift colleagues work a four-team rota of twelve-hour shifts, with a duty manager on every shift at each campus. The hardest part of shift operations is not filling the hours but keeping judgement consistent across them. Since 2019 every planned electrical operation has had a written method statement, a second authorised electrician checking each step, and a daytime window when engineering support is on site. Emergency operations follow pre-approved procedures that night teams rehearse each quarter. I review near misses monthly with the duty managers and publish what changed as a result. Overtime and consecutive night shifts are capped, and I treat a breach of those caps as an operating failure to be explained, not as admirable commitment by the people who worked the extra hours.
05
Dividing data-security duties between host and customer
Our managed private-cloud customers place production, supplier and sometimes consumer data on platforms we operate. Under China's Cybersecurity Law, Data Security Law and Personal Information Protection Law, responsibilities differ between the customer, which decides what data it holds and why, and ourselves, which operate the infrastructure, the physical security and the administrative access. I make that division explicit in every service description. My teams maintain the multi-level protection scheme assessments for the platforms we run, log every physical and administrative access, and separate customer environments so that an engineer working for one customer cannot reach another. When a customer asks us to take decisions about its data that properly belong to it, we either contract for that responsibility in writing, with its scope and limits stated, or decline the work.
A leadership conviction
I think of a data centre as a set of promises about what happens after something breaks. The equipment can be bought. Keeping the promises depends on writing them down honestly, selling only what they allow and training the people on night shift to act on them without waiting for permission. Most of my difficult decisions have been about refusing to let a sale, a schedule or a budget quietly rewrite those promises.
Start a conversation ↗