Do you think NoSQL database means the end of DBAs?
I don't think we've ever really thought about that specific question. When we consider the administration capabilities of Oracle NoSQL Database, we generally don't think of "lights out" administration (even though our heritage is in the Berkeley DB group where lights out administration is assumed). Hence, we have the Admin Console facility for monitoring and administration purposes. Of course, it is always our goal to minimize the amount of administration necessary by making things as seamless as possible for monitoring and configuration of the system. That is just plain common sense since no administrator wants their job to be complex or messy. Given the potential scale of NoSQL Database topologies, it is necessary for us to design the administration capabilities so that we maximize the number of systems that a single administrator can manage.
In my opinion, while everything is trending toward automation of database related activities, a complex persistence/database technology stack (based on NoSQL, RDBMS, etc.) will always require care and feeding by someone, particularly as the associated deployment footprint increases.
Whether the job is characterized as a DBA position or not (e.g. it could move toward more generalized position such as DevOps), I think it will be hard to completely eliminate human oversight.
Definitely not the end of the line for DBAs working on traditional RDBMS. As long as there are Oracle RDBMS, SQL Server, DB2, etc in the world, there will be DBAs needed to support it. When it comes to NoSQL and other big data related technologies (Hadoop) the administration focus shifts a bit more towards system administrators and developers. Think about it, instead of building indexes, adding data files and traditional performance tuning, NoSQL requires a different skill set. Instead of new data files, a new node might be stood up. Instead of looking at explain plans, a JAVA based MapReduce program might be tuned...it's a different skill set, not the end of the DBA.