Tips for separating DevOps Git repos?
When considering mono-repo vs many-repos you might look at the following questions, which should also affect the composition of the code directory tree structure. There is a slight general trend toward mono-repos.

Discoverability

How easy it is for developers and ops people to discover the code for some feature. Are there clear guidelines on what goes where? Are they enforced somehow through automation? Are new repos automatically linked as submodules into correct location? Does the build or deploy process depend on the tree structure making sure people need to put it there in order for it to be even noticed? What is the size? How long it will take to grep code in certain place? Are there generic lib/ directories where devs and ops end up sharing libraries that create new unexpected inexplicit dependencies?

Deployability

Does any of the code need to be present on machines that you deploy to? Are you expecting to do such deployment through syncing repository or do you have other established deployment mechanisms. In the first case, will other code creep in during the deployments that does not need to be there?

Durability

Will the concept you are using stand the test of time? Are you a one product shop, but maybe in your future there are new products? How would adding a new product affect the code? Will there be new mono-repo for the new product? What about shared code between products? Looking at your company roadmap, how will whatever you do fare 6m, 2y, 5y down the road? Choices like this tend to be hard to change in practice (even though they shouldn't - in theory).

DevOps

You really want to take down barriers between Devs and Ops. So even just having separate mono-repo for ops could create such barrier. The operation and deployment of code, standing up environments, setting up services, it should all be in reach of developers and with explicit expectations to develop such code in coordination with the ops team, not being dependent on someone doing it for them. If things go well your developers follow through with code for months after it has already been in production and have hand in all aspects of the deployment. How easy it is to make commits that contain both product and deployment changes? How can those commits be grouped together? What is the visibility of ops into product runtime code and devs into product management code?