I agree with the highly voted answers that basically say "this is not your problem" but
I'm writing an answer to frame challenge your question, and the conclusion that there is actually a problem, because I think there's a learning opportunity present in this issue that's being glossed over.
Companies make decisions about who does what work based on a number of factors. From an employee's perspective, this can be confusing and very easy to misinterpret for a number of reasons:
- Sometimes they change over time, or are inconsistent
- Sometimes they're intangible, or unconscious "gut feel" factors
- But often, they are related to factors that individual contributors don't have any exposure to or direct knowledge of, like budgeting, resourcing, or professional development plans for other individuals
Because of this, it can be really hard to interpret work assignment decisions - which is a big part of why the "it's not your problem to solve" answers are correct, but should probably be taken a step further: it's not really even "your problem" to identify as a problem.
This is relevant to "bus factor" issues because individual contributors are often not in a good position to understand the bigger picture about how decisions are made, and can miss important factors. Something that looks like a problem to you might be perfectly okay to the leader who is responsible for it.
As an individual contributor, it might sound ideal to have full redundancy on every role, fully trained and capable backups for every single process, and a team of people who are expert in every skill instead of just a single person. Having every single process documented to the degree that any person could pick the documentation up and solve any problem would certainly reduce the stress for everyone!
However, from a leadership position, when you're trying to balance expenses and profits against risks, taking that "back up every person and always have a plan B for everything" approach would likely be prohibitively expensive.
My first exposure to this sort of decision making process came early in my career, but in a slightly different context: maintenance management and the science of reliability and preventive maintenance planning. I was working in a software role for a consulting firm that set up asset management software for large utilities, including several water treatment facilities. Our software could manage regular preventive management programs for every piece of equipment in the facility. However, I quickly noticed that many of our customers chose not to perform preventive maintenance on some of the equipment in their plants. That was a little alarming to me: wouldn't you want to rebuild that pump every year, and thus keep it from ever failing? Isn't the ultimate goal to reduce or eliminate failures and corrective maintenance, no matter what? And shouldn't there be a backup sitting right next to it, so the process can continue when there is a failure?
Ultimately, I learned that the goal isn't redundancy and prevention at all costs: the goal is to achieve the lowest total cost. Sometimes, that means letting a certain pump fail. Of course, the pumps that were critical to the operation got careful preventive maintenance and had online spares, so failures were rare, and even if there was a failure, it would be handled just fine. But the pump for a less important process didn't have any backup and wasn't regularly maintained. When it failed, it might cause some disruption, but it was addressed and life went on. It was - quite literally - not worth having redundancy for that pump.
The same approach holds true in process management for IT and knowledge workers. Sometimes, there are processes or infrastructure that are quite critical to the business. Those should have contingency plans and lots of attention. But the server sitting in the corner that's a test bed for something not critical to the mission? It might not be important for anyone in the company to understand every little nuance of how to manage it, much less for there to be two people who do. Basically, the lesson is: just because some task doesn't have full documentation, full staff redundancies, and 100% knowledge sharing, doesn't mean there is an actual problem that needs to be solved. Most organizations are chock full of processes that aren't that thoroughly shored up, on purpose. Organizations make decisions about how much they are willing to invest in things like cross training, redundancy, and knowledge transfer, and those decisions often legitimately result in do nothing, let it fail and we'll figure it out.
To bring this all back around to your specific situation:
On the one hand, you need to look out for yourself. If your employer is doing something that clearly has a negative impact on your career, or puts you in a position you're unhappy with, you should identify that and seek to work with your boss to resolve it - or, get a different job if it's not something the employer will budge on. If you are worried about "bus factor" because your employer is abusing the employment relationship by preventing you from taking vacations, or calling you every night at 2 AM to reboot servers, then you should absolutely raise that as a concern.
But, if your concern is simply that you're the only person who knows how to do something, or the only person responsible for doing a specific task, and there are no further actual ramifications that impact you personally, that - in and of itself - might not actually be an issue. If you are concerned because of the potential impact to your employer should you not be available to do that task, you should raise that concern. But, your employer may have legitimate reasons for not changing anything, if they determine that the risk is acceptable based on their plans. In this case, reporting the issue will help get it off your mind, and then you can move on with life knowing that it's not your problem and you've alerted the people who are actually responsible.
If you do decide that being in this situation makes you incredibly unhappy regardless of all of the above (or if your employer is abusing you), and you're unhappy enough to decide to look for another job, make sure you take a step back, identify the factors that lead to your unhappiness, and evaluate potential future employers based on those factors. If you don't want to be a single point of failure in your next job, make sure you research potential employers to learn how likely that will be - for instance, working for a tiny startup will probably be a bad idea, because in a tiny startup, pretty much everyone is a single point of failure all the time. But on the other end of the spectrum, an large and well established employer in a tightly regulated field like healthcare or finance will likely have thorough redundancies and lots of cross training - that might be a great environment for you.
Also, as you interview, make sure you ask relevant questions that give potential employers the opportunity to explain these factors to you. You can ask about team size, cross training, work assignment, or other related factors, in order to help you determine if that employer is a good fit for you or not.
Or, if you find yourself in a position of really wanting to actually be the person who decides these sorts of things for a company, consider working your way into leadership roles, where you can be in the driver's seat of addressing things like the bus factor, instead of just being the "victim" of someone else's choices.
