I agree with those who have commented that the role you describe doesn't really match a typical DevOps role. However, there are certain things you won't be able to change in your organization. Instead, focus on the things you can do.
Understand the Objectives
The best place to start is with a clear understanding of Service Level Objectives. What kinds of things do external customers actually care about? If they don't care about uptime, don't make uptime measurements a high priority. Perhaps latency, software updates, content accuracy, or some other measure is more important. Also be aware of your internal customers' needs (your boss, coworkers, etc). What things do they care about?
Once you understand what is most important to your customers, measure, measure, measure! Get as much data as you can about those items that matter. How long does it take to deploy code? When you close a ticket, what percentage of the time does it come back unresolved? And so on. Use those measurements to improve over time.
Here are some areas you can focus your efforts (varies, depending on the company you work for):
If someone logged into a server and broke the configuration, how hard would it be to correct the error?
- You should be able to consistently build and replace resources with minimal effort.
- Configuration management should be complete so that all meaningful changes are tracked.
- Ideally, build up processes or tooling as needed so that developers can modify configuration themselves in a controlled and collaborative way (:D DevOps!).
When new code is released, how does it get delivered?
- When code is pushed to source control, it should trigger automated testing and deployment. If possible, this should happen in a pipeline that deploys multiple environments in sequence as tests pass (dev -> qa -> uat -> prod).
- Improve visibility so that you can easily see where different versions of the code are running, what errors are occurring, and how performance is changing.
- Enable your software developers to deliver code themselves (:D DevOps!).
- Collaborate with developers to improve this process (:D DevOps!)
When something goes wrong, how quickly can you find out what the problem was? If something went wrong 2 months ago, can you still find out what the problem was?
- Collect logs in a central place with tools that help you search and visualize.
- Aggregate metrics with tools that help visualize.
- Reduce noise! If it's not meaningful, don't keep it (but be a little conservative, sometimes things turn out to be meaningful later).
- Work with developers to understand how logging and metrics would help them deliver better software (:D DevOps!).
Ideally, you should not ever need to look at a graph, dashboard, or log message, unless there's an actual problem to solve. Sitting and watching a dashboard is not a good task for humans.
- Set up alerting so that you get notified when problems arise.
- Alerts should go to ONE person, who is the RIGHT person.
- Alerts should be urgent (needs to be addressed immediately), and actionable (the person getting the alert can fix it).
- In the spirit of paging the right person, you may be able to work with developers on getting them into some kind of on-call rotation (even just M-F 8-5 for a subset of code issues). (DevOps?)
If your servers were destroyed today, how long would it take to be up and running again?
- Take backups of data and set up backup infrastructure.
- Test backup recovery regularly.
- Test failover to secondary infrastructure regularly.
- Work with developers to better understand how code will operate in a failover scenario and improve as needed (:D DevOps!).
Heaven forbid something happen to you, but if it does, how well can someone else replace you. Document what you've built and improved so clearly that another person can replace you. Don't worry, this makes you less likely to be fired.
Always, educate yourself. Take online courses, read books, work on certifications. I don't know what the path looks like for you. I believe that spending a few hours every week specifically dedicated to improving your own skills is a valuable use of your time (even for your employer!).
A book like Site Reliability Engineering (Beyer, Jones, Petoff & Murphy) or The Phoenix Project (Kim, Behr & Spafford) might be good to read on this topic.
Totally possible I've entirely missed the point of your question. If so, I apologize. However, I think this ought to give you some ideas of how you can spend your time in ways that is worthwhile to both your employer and yourself.