It depends what kind of issues you are facing. "Fixing the environment" is somewhat vague, and lack of precision in describing the problem might in itself be a reason it is hard to get solved. If the problem is unclear it is also unclear who is responsible for fixing it.
You have to break the perceived problems into concretely described issues with steps-to-reproduce and so on. Then you get the issues prioritized and scheduled like all other development tasks. If an issue cause extensive downtime for QA it should be easy to get the fix prioritized, since downtime is pretty costly. (At least if management is halfway rational. If not, then your organization have management problems which are outside of the scope of this forum.)
If the downtime is due to software releases frequently introducing bugs, then you have to redefine your "definition of done". A feature which causes the development environment to crash is not "done".
Looking at your examples it seems QA is (or should be!) your friend here. If the development environment is down or unresponsive for whatever reason, then a feature should not be accepted by QA. If development is feature driven, then everyone have an incentive to get these issues fixed, since a feature is not considered delivered before QA accepts it.
Two of the point demands special consideration:
The database is slow. If the database is functional but slow it is not obvious if QA should accept a feature. Here you will have do define acceptance criteria for performance of the system. Eg. "User should see the response screen within 2 seconds after pressing the OK-button".
External systems are down. Well, you don't have any control over that. You migh have to look into SLA's to see you you can force them to fix their issues. If it is a recurrent problem you will have to find alternatives or make your system more fault tolerant.