What are the best techniques for fixing server issues?

Whenever server issues arise, first check the logs and monitoring tools to identify what's going wrong. Sometimes, a simple restart can fix the problem. Make sure everything is up to date with the latest patches and updates. Look over the server settings to ensure they're optimized. If the problem persists, try turning off non-essential services and re-enabling them one by one to find the culprit. Keep regular backups so you can restore things quickly if needed. Document everything you do to solve the issue for future reference. This methodical approach helps keep your server running smoothly.

Basic steps should be consulting Event Viewer. It is by far the most powerful tool at your disposal. There you can find amy and all errors that plague your server. From the info you will obtain from EV, you can narrow your search and/or tackle the problem. Be it a network issue (tracert, ns lookup etc...), performance issues (tasmgr, resource monitor, etc...), or other issues. Event Viewer together with your monitoring tool of choice (PRTG, Grafana, etc...) will make maintenance very much easier and faster.

Gathering information would be my first step, not "identify symptoms". I usually try to answer the Three Questions: 1. What's happening? (What's the problem and if it's not obvious, why it's a problem, i.e. what's the impact?) 2. Any additional information, such as: is it the 1st occurrence, and if not, how long has this been happening? Is the issue associated with any errors messages, logs or events, or any other context? Gather that info, log it. 3. Has anything changed before the issue happened or started happening? (OS reconfiguration, component added or removed, etc.) Answering these question usually clears up 99% of issues, or allows to quickly zero in and mitigate it.

Indeed! If the server doesn't power up, swap the power cables, test the power source and the power supplies. If they're all good - only then continue into the server's IPMI/iDRAC/iLO to check for issues and to look at the health logs. Having spares around (servers of the same make / model, power supplies, drive modules, etc.) - helps a lot in this. It often helps not just to isolate the problem, but to quickly fix it as well - by replacing the entire server, or a part of it.

Once you've identified symptoms pointing to a server problem, it's important to isolate the issue to prevent wider impact. For example, if a website or application is responding slowly, you could take it offline or limit access to isolate the slowness to that service. Or if a server is having hardware problems, you may want to take it out of the load balancer rotation. Isolating the issue prevents cascading failures and lets you focus remediation efforts. Use monitoring data, testing, and logical reasoning to narrow down root causes. The more precisely you can isolate the problem, the faster you can address it.

Besides the usual research stages of RTFM and scouting vendor forums, StackExchange or reddit, can't recommend one other thing highly enough: Log your research in the ticketing system or on the appropriate forums (while being mindful of not sharing confidential or sensitive info if logging publicly). Ideally in a ticketing system. Every step of the way, everything you've found or tried, not matter the result. This can and will help tremendously if a similar issue occurs in the future and some other poor soul is in the same shoes. Else the hours of research and the wisdom it took to resolve the issue - are irretrievably lost for the future.

Before applying, check if there's a rollback option. Trying to update the iDRAC firmware on an old r610 so it can be accessed w/o invoking IE mode and re-enabling TLS 1.0? Unless the server is slated for decomm and can be freely bricked - ensure the update can be rolled back. Making a major change to the OS running on a physical server? Make a backup or clone the entire system. (a P2V might be a good option here.)

A ticketing system is best and please, please, please, don't just say "fixed". Document the problem, the context, the impact, the steps taken, and what it took to resolve an issue - all of it. No time? Not an excuse. Keep notes, then add them to the ticket ASAP. No ticketing system? There are still options: Start a chat thread (Slack, Teams, etc.) in an appropriate shared channel when troubleshooting something or making changes. Any new info, action, change - a new comment. This makes it super easy to escalate to others, and to keep it visible. If someone yells, "I can't ping the DC, WTF!?", calmly share the thread's link with them. Nifty, right? :) A personal "work journal" is also a great idea in the absence of a good ticketing system.

It's often easier to stop something happening in the first place than to repair the damage after it has happened. In my experience preventative maintenance and proactive server monitoring has been key to minimising costly system downtime. By implementing proactive monitoring and maintenance solutions, you gain technical insights and receive alerts about minor issues before they escalate, saving you valuable time, money and technical headaches.

I agree with all what's mentioned before, but initially you have to understand how are your servers and systems work, then you can start investigating!

What Jonathan Lawton said, in slightly different words: "An ounce of prevention is worth a pound of cure" (proverb) Planning for failures and issues by way of regular maintenance, monitoring, equipment refreshes and capacity planning - is likely one of the most effective ways to prevent catastrophic or any other failures. Yet it's also often the most neglected job... unless you're an SRE. The SRE discipline, even though it's focused on distributed applications more than servers, really digs into cost of failures and what it takes to minimize their impact. It even touches on team and company culture principles enabling effective failure and risk mitigation.