peak_foto

It is 4:00 p.m. on September 8, 2024; the day is bright and clear. I´m leaving the majestic crater of Mount Fuji behind me, returning to the rim. From its 3,776-meter summit we can gaze out over kilometers upon kilometers of Japan in every direction. We reached the top after a good couple of hours of climbing, stopping by on the stations for some hot tea and even a pack of M&M´s, purchased back at around 2,800 meters. Every mountain is a world in itself, and Fuji is quite different from Teide. They are all majestic, and Mount Fuji is no exception: an imposing vantage point visible, on a truly clear day, even from as far away as Chiba, as we were fortunate enough to discover a few days later. I am happy, absolutely elated; this is my second peak over 3,000 meters. Yet, amidst all the joy, the scenery, and my own repetitive, frequent remarks “This isn’t like Teide, is it? Though it does look a lot like Chinyero” something has been gnawing at me for the last hour or so, though I can’t quite put my finger on what it is yet.

We reached the summit alongside a couple of French-speaking Canadians. We crossed paths with many people, including a group of highly motivated Japanese students who were cheering everyone on during the ascent, they were even wearing hachimaki and everything. And although I can speak a little bit of Japanese, we found it easier to communicate with the Canadians, using both English and French. Our climbing paces were more in sync, we shared the experience of being gaijin, and we had two languages ​​in common. (Note: I don’t speak French, but that’s one of the perks of having a French translator with you!)

And there we were, enjoying the summit, taking photos and the like. I can’t help it but my mind is already on the next milestone: the return journey. From the Fuji Subaru 5th Station, the way we came, following the Yoshida Trail, and the way we’ll be heading back… when does the last バス (bus) leave? It’s a little past four, and a foreboding shiver runs through me. I pull out my phone and check the photo I took of the bus schedule:

timetable_foto

Oh, right. The last one leaves at 18:45. That gives us about two hours to complete the descent, the climb that took us over five hours. “Not great, not terrible.” I sound a bit worried as I say it. Besides, at the latitude of Mount Fuji, unlike in the Canary Islands, where you still have daylight well past 20:00 in September, here it means darkness. Suddenly, I’m gripped by a sense of urgency. If we don’t make it on time… well, who knows what that actually entails? Are there タクシー (taxis) at the 5th Station? And if there are, will we even be able to catch one? After all, it wasn’t just a handful of hikers we passed on the way up. We mention this to the Canadians, and after taking one last moment to soak in Japan’s axis mundi, we prepare for the descent. We make a pact with the Canadians: if we don’t make it in time, we’ll share a taxi to Fujiyoshida to split the cost.

And so we began the descent. Have I mentioned that Mount Fuji isn’t like Mount Teide? It consists primarily of dark, unstable volcanic gravel, what we call picón. It’s not the kind of terrain you can descend carelessly, unless you want to fall and end up going down very, very fast.

The Need for Speed

We needed to move fast. We needed to move fast because there was a clear deadline, and the only way to meet it was to accelerate. This applies to the Fuji climb, but it also applies to most software releases, to any change that Product deems necessary: ​​Dev must rush to implement it, and Ops must rush to deploy it. This isn’t just about being in a hurry for the sake of it; it’s not rushing just to rush. There is a deadline to meet. And usually, that deadline isn’t arbitrary, missing it carries clear consequences. In the case of Mount Fuji, it could mean paying the extra cost for a taxi, or ending up stranded with no idea how to get back to your hotel. In the context of software, it could mean increased costs, reputational damage, or customer churn whether it’s a missed release, a hotfix that isn’t deployed on time, or a configuration change that arrives too late.

So, we had to speed up, move faster. The risk of not doing so was quite clear and significant. And I’m not just talking about missing out on a good soak in the hot, very hot, water of the hotel onsen, or skipping dinner… which, believe me, was a prospect that weighed more heavily on me than you might imagine. The thing is, as soon as I took my first few steps on that unstable gravel, I realized that rushing at any cost wouldn’t work. One slip, and the best-case scenario would be an embarrassing fall or a twisted ankle. It could be worse, though: acting foolishly at three thousand meters can end in a helicopter evacuation, which is incredibly expensive, and a completely ruined vacation. We’re talking about the difference between a minor incident (missing dinner) and a very high severity incident (breaking a leg and goodbye vacations).

In SRE and DevOps, meeting a deadline also carries risks: a poorly tested change can have an unexpected blast radius and a release that hasn’t been thoroughly tested might end up introducing a bug more serious than the one it was intended to fix. If we focus on meeting a deadline at any cost, we may lose sight of something crucial to reliability: the price of meeting that deadline poorly can end up being far higher than the cost of missing it altogether.

So, on the descent from Mount Fuji, the plan was clear. Move as fast as we could, while staying safe, and if that meant missing our deadline rather than ending up on crutches, so be it. We kept up a good pace, a very decent pace in fact, but always one that allowed us to maintain our footing without slipping or skidding on the loose gravel. As the sky darkened, fog began to roll in, lapping at the lower slopes of the mountain. Instead of obsessing over how much ground we had left to cover, we simply focused on placing one foot firmly in front of the other, all while being careful not to wreck our knees from exhaustion, since pushing too hard in the mountains is another sure-fire way to end up with an injury. It was around 18:30 when we reached the Fuji Subaru Line 5th Station trailhead; from there, the path turned into a wide, straight dirt track with no further descent. My knees were aching, they’d really taken a beating, but we had made it!

… And there was a line of about fifty taxi drivers, with just as many others queuing up, at the trailhead on both sides of the road, waiting very respectfully. They saw us arrive, bowed in greeting, offered a subtle smile, and went right back to waiting as we walked past. I don’t mean to offend them, but I must confess that the image of vultures crossed my mind. So, we arrived, met our deadline, and then had to wait until 18:45, spending about ten minutes sitting in the dusk light, eating an energy bar and smiling. And then I laughed even harder, because if we hadn’t arrived on time, the problem wouldn’t have been finding a taxi, it would have been deciding which one of them to choose.

Move fast, but stay safe

This is a principle I apply, and observe in SRE, whenever I can. The sense of urgency, or even the near-catastrophic feeling that arises when a deadline approaches, must not cause us to lose our cool. Moving faster might seem like the right approach, but if you end up with a broken leg, you’ve acted foolishly. Even if you didn’t actually break a leg or burn yourself out, only to realize that missing the deadline slightly while prioritizing safety wouldn’t have been catastrophic, you might still feel like a fool. Or, at least, you should. In mountaineering, just as in Site Reliability Engineering, it’s not only about speed, it’s about a tuple: (speed, safety). Moving at the maximum safe speed is the smartest approach, and the most reliable approach. It’s also smart to have a backup plan in case a deadline isn’t met. In my experience, most “deadlines” aren’t actually that full of death. As leaders and change managers, we must never be unjustified blockers, but we should be the ones who keep a cool head, making realistic assessments of operational risk and timing. That way, we ensure no one ends up with a broken leg, only to miss the deadline anyway.