There are a lot of specifics that make networked gameplay much harder to debug, but in very very general terms it comes down to 2 basic points:
- Error can arise from a much greater set of potential sources than client-only gameplay.
- It's hard to insert debug tools into live instances, especially when huge volumes of data are being manipulated.
Usually a multiplayer game has a lot of specialized servers working together (lobby server, game logic, etc.), and many times multiple databases. An error can come from any part of this system such as a bug in your game server software, too much load on the server, incorrect server configuration, bugs or unexpected behavior in the client that send incorrect commands or data, etc. Since you can't easily use a debugger on this live code, usually most companies make use of Logging (either with their own logging tools, open-source tools, or commercial logging packages like Loggly) to debug and then also use specific tools to monitor key system performance metrics.
Keeping an eye on issues in a live environment is a MUCH more in-depth instrumentation, and requires administrators to keep an eye on constantly.
As far as design, even if you use a commercial networking package (like a commercially available networking library, game server or a PaaS/SaaS game networking tool) there's still a lot of fundamental architecture decisions you have to make for your own specific style of game (for instance, are you turn-based, real-time, %100 asynch?), no package will do that for you. So networking while engines provide tools, they don't free you from needing to know networking and network programming principles.