Voice of the DBA

Tag: DevOps

  • DevOps Deja Vu with Oracle

    While I was out on sabbatical, I took a two day break to attend an Oracle conference and speak. The Rocky Mountain Oracle User Group Training Days 2020 was held a week ago a little North of Denver and I was there to speak about DevOps.

    In many ways, this was similar to the talks and discussions I’ve had with SQL Server developers and DBAs across the last seven or eight years. What was different, and fascinating, is that most of the Oracle people were in the place that lots of you SQL Server people were about 3-4 years ago.

    Not that we’re all in the same place, but between the work I’ve done with Redgate and the messages from Microsoft, many SQL Server users get the idea of better development and now are trying to work out the mechanics of implementing things. In the Oracle world it seems that many people are still trying to decide if they should change any development practices and what options are out there.

    It wasn’t just me. I watched 3 other DevOps talks and they all were similar. The message was more on what DevOps can mean and how it changes your work building software. In the MS world, we’re more often focused on the mechanics of specific ways to move to a more DevOps style work environment.

    Redgate is moving to release more tools for Oracle and other platforms, and we’re evolving the way we build these tools to help more groups. I’m looking forward to spending more time with Oracle procs and brushing up a little on my PL/SQL skills.

  • Get the 2020 State of Database DevOps Report

    It’s live and available. You can download the report now and see how your software development might compare with others, and even get a few hints on what your organization might try to produce better software today.

  • A Problem with Cowboy Coding

    As we implement more automation and complexity in our systems, we increase the ability of every worker to accomplish more during their day. In many cases, this is a good thing, as many of us have no shortage of tasks to complete. Being able to do more is good. Some technology workers, and likely some managers, view these changes as opportunities to use less people to do the same work. That can be worrisome for many people, especially those concerned with job security. That’s a difficult situation to find one’s self in.

    I’m not sure if this worker was concerned about losing employment or just wanted to get more work, but a contractor put logic bombs in his project that would cause issues at various times. He would then be called to fix issues, getting paid for his efforts. Recently he was sentenced to prison time for his actions.

    Most workers make an effort to do good work and provide value for their time and knowledge. They may still make mistakes or cause problems, but it’s often unintentional, not malicious. We also don’t look to create future problems for others, though certainly we may accrue technical debt over time as we make trade-offs in our work.

    Whether intentional or accidental, we want to limit mistakes and issues in our code. This is one reason that modern development in a DevOps environment isn’t a wild west, cowboy style of work. We use code reviews and continuous improvement to help other developers learn to write better code. We use automated processes with instrumentation and logging to ensure we know what code is deployed when and by whom.

    We may move faster with DevOps, but it’s often safer, more secure, and more accountable than previous methods of building software. It doesn’t prevent mistakes, but every part of the process should be more transparent and auditable, which is good for everyone involved.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Quick Security Mistakes

    How many of you have gotten an urgent request from someone in your organization? Maybe it’s a new database, perhaps a quick, “simple” change to an application, possibly even a new server or share that someone can use to complete their work. It’s something new that you need to do. When that happens, how many of you ensure that you follow all the same steps and protocols to comply with the urgent request?

    A few of you do, but when we’re in a hurry, many of us don’t necessarily complete every step. We may shortcut something to get work done. We may have the best of intentions to go back and complete the work, but in a busy environment, it’s easy to forget to complete that last step, which might be configuring security or running all or unit tests or even decommissioning some resource that a user is done using. Some of you will realize these are big missteps, and some of you will still make them.

    Someone at the Department of Transportation in Coloroado (CDOT) made a mistake like this (thanks to DCAC and Joey D’Antoni for the story). They stood up a virtual machine, connecting it to their local network, but failing to properly secure it. In this case, the machine was exposed to the Internet and connected with a domain admin account. As you might guess, someone got into the machine and executed a ransomware attack on CDOT.

    As Joey points out, a few mistakes were made here, but these are the types of mistakes that anyone can make. Lots of us follow a process over, and over, and over again. Until we don’t. Until we’re distracted, busy, or in a hurry. They we take a shortcut. Most of the time nothing happens, but most of the time is becoming less acceptable. All of the time is the standard, which is why we try to use a DevOps, GitOps, or other process that ensures all the steps are completed. Not most of them.

    Do yourself a favor and build processes to handle your tasks with a script or the push of a button. Ensure the operations are logged and audited. Use these processes to be sure that setting up a new system, database, application, etc. is done in a consistent and secure manner. There’s still plenty of work to do for all of us. These processes will grow and change over time, and need to be maintained. Use your brain for the hard problem solving task of building a process and let the computer execute it, the same way, to completion, every time.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.