Deciding on a replication strategy
You're right about each of your options.  Log Shipping is perhaps the easiest way to almost accomplish what you want, but there is the drawback that you won't be able to read from your secondaries while the logs are being restored.  If your goal is simply to become more highly available in case something bad happens, I advise you to at least get your backup strategy up to speed ASAP.  That means putting your databases in FULL recovery mode and performing transaction log backups at a high frequency, and putting those backups on a different disk than your database and transaction log.  

One thing you didn't mention was creating a simple shared-disk cluster.  Again, it depends on what type of redundancy you want.  If you're just trying to ensure against a server hardware failure, this might be the way to go.  

The technical solution to your problem that gives you the highest availability and flexibility is to upgrade to SQL Server 2014 Enterprise Edition, which has support for AlwaysOn Availability Groups.  AlwaysOn is a technology almost identical to mirroring, but allows for a readable secondary (to be sure, there are other benefits).

That upgrade can be costly, however, since it requires Enterprise Edition.  It's also pretty tricky to configure the first time, and you'll need to make sure you have a good relationship between your DBA-ish people and network administration team to pull it off.  It may even be worth hiring a consultant for this setup alone if you really don't have the DBA resources.  Just make sure the consultant has experience setting up this type of cluster.  It IS something you can pull of yourself if you know enough about networking, security, clustering, and SQL Server, though.  All the resources are out there, you'll just have to do some digging.  Brent Ozar has some good resources you can check out, but you'll probably want to look into a book purchase.

Another nice thing about AlwaysOn AG's is that you can set up an Azure instance as your secondary without making another hardware purchase.  This can be a really smart for DR scenarios where your main data center goes out -- you'll have Azure's completely separate infrastructure to fall back on. 

Sorry, I think I didn't answer your question too well, I think I just gave you a lot more to think about.  That's how this goes, I guess...