devopsy.kinsta.cloud

Tag: chatbot

  • The Right Tool for the Job: AI Edition

    The Right Tool for the Job: AI Edition

    (Actually, the right job for the tool.)

    We are currently in a really weird space with regard to AI capability. For my AI friends, I will make the disclaimer that what we call AI today is not actually AI, it is more akin to LiSP “AI” than actual intelligence (and, in reality, is firmly somewhere in between). In short, we have great language processing tools that we call AI but that have no cognitive ability—but, man, are they useful.

    And the suddenness with which the rest of the world realized they were useful was nothing short of astounding. One day we are using AI algorithms to process test results and filter security data; next thing you know, our business people are bringing up AI and how advanced it is in every meeting.

    They’re not wrong, but we need to differentiate the technologies. The promise and danger of chatbots is not the same as the promise and dangers of AI in security (where it can be used by attackers as easily as defenders, btw). We’re going to have to work out the concerns and benefits in real-time, but we need to start by pushing back and making clear that it is not a panacea, any more than the last 50 technologies that came along. It has great promise to change the world, but so did VMs and Java and containers and …

    This one seems bigger, but that’s largely because it came on so fast and with seemingly broad applicability. But in the end, it is good at processing large datasets and noticing both patterns and anomalies in the data. This is a great, hugely powerful tool, but for things with sparse data? Totally useless. This is critical to remember moving forward. AI that monitors a certain aspect of security in the organization can detect patterns and anomalies, but unless the dataset is massive, there will be a lot of false positives along the way, and a more traditional tool is preferred. If that same AI (same software, algorithm, etc.) is being trained on data from hundreds of companies? Sign the check, it’s probably going to be better and more forward-looking than your current solution.

    And that’s the key. It took the entirety of the World Wide Web—including, I might add, The Gutenberg Project—to train the language processors, so unless that security AI has a massive dataset, it’s not likely ready for prime time.

    In IT, look to AI today (and this will change relatively rapidly, so check back often) for large dataset processing and for advanced automation. Those are the two real use cases. More will come, but right now, the ability to find patterns in large datasets or to say, in real-time, “A+B+C = block that port!” are the biggest viable use cases.

    Over the years, I have grown ever more skeptical of claims about removing the need for developers. Those claims have been made so many times that my friends and I have a stable of jokes about them. Java, XML, 4GLs, RoR, UI generation tools—the list goes on and on. And each one created even more code. I expect AI will be the same, but there is no denying it can offer initial frameworks, much like mobile UI generation tools do. We’ll have to see how much change that bit introduces.

    And keep rocking it. While I hope my readers don’t need reminding not to upload their source code to any of these AI tools, I will point out that your (Dev and Ops) source is so proprietary and critical that employers freak out when it is uploaded to an AI chatbot. No one cares what is done with chatbot-generated source, but the DevOps team’s source is considered critical. Sleep well knowing that.

  • In DevOps, Chatbots are a People Problem

    In DevOps, Chatbots are a People Problem

    By now, you are undoubtedly aware that you can call up a chatbot or install an AI assistant into your IDE and generate entry-level code and deployment scripts.

    Indeed, if you just go to a site like ChatGPT and enter “generate Python code to do X” where X is something you need to be done–or an example like “read a file and print out the contents one line at a time,” it will do it. And if you keep it simple, it will do it well. If you say “again, in Java,” it will comply and do it well.

    Then say “new chat,” and tell it to “write a bash script to deploy an app named X written in Java and using Gradle to a cluster named Y,” it will do that also, informing you of the names of the deployment and service YAML files. Then you can say, “generate the deployment file mentioned,” and it will. And then you can say, “parameterize the Java version,” and it will do that, too. This iterative revision can continue until the deployment code, containers and deployment files are complete. If you have not yet, I urge you to spend the half hour going through these steps once required, so the potential is obvious.

    It is not yet to the point where I would (or you should) trust it with complex systems, but all of that busy work we’ve been trying to overcome with templates and preconfigured containers? We can actually get around the bulk of it now. The same is true for testing of all kinds. There are tools that will auto-generate test scripts for a given set of source code. They will also generate test execution code. That means that the only step left—and the one that has held testing back because of the volume of work—is reviewing results … But wait, there’s more! In security testing, AI can help eliminate false positives. In performance or QA testing, it can filter out all but the most egregious issues (as defined by the org or by a larger pool of apps).

    The problem we need to address today is the people issue. What we have traditionally used entry-level people for—and trained them in Dev/Ops/DevOps with—is no longer necessary. Because the AI can do it. That is stunning and really very cool, if you think about it.

    But it heralds a danger that every org needs to be aware of. What we do and how we do it is changing. For the better, but change always brings uncertainty, and the foreseeable bit we need to confront is, “Now that we don’t need entry-level people for these steps, how do we recruit and train them?” I do not yet have a definitive answer for this question, because I am a product of my time, so I see things in terms of learning the bits that make up the whole—advising people interested in DevOps to learn at least one Linux command shell, to understand how networking works in containers, to write the scripts to get containers (and/or public cloud instances) up and running, etc.

    I do think that every org should start using these tools at a pace that makes them comfortable because it allows us to continue our “more with less” growth without significant pain. But we need to make certain we are training the next generation of DevOps engineers in the process. For the foreseeable future, we’ll still be the ones bug fixing and troubleshooting, so we need to understand the environment and the applications. We are starting to get some sweet tools to help us at a higher level, though. Anyone who has inherited complex systems knows that the learning curve of tons of source files that make up many subsystems and all of the spaghetti code that these can be comprised of is painful. I don’t normally mention brand names here, so I’ll just say there is at least one tool out there that you can ask to “describe what this code does” and it will run with it and give you an answer in plain English. This might be the training tool of the future, with the ability to compare what you see in code with what the AI describes in English.

    But for now, even if you don’t hunt down app description AIs, having entry-level people review the files that the AI generates will serve two purposes: First, to validate what the growing AI space is capable of and second, to get entry-level engineers into the entry-level bits of the systems.

    And keep rocking it. Make sure you have a path for DevOps in the AI future, but remember that the creation of the calculator did not statistically change the number of mathematicians, just made the bulk of them more productive. That’s all we’re doing here, just a bit more flexibly … But in the end, like a calculator, the AI has an equation that it fills and reports back with.

  • 3 Performance Challenges as Chatbot Adoption Grows

    3 Performance Challenges as Chatbot Adoption Grows

    Today, many organizations are starting to use voice or text-enabled chatbots for the first time or already have chatbot systems in place. In fact, Gartner said 25% of organizations are predicted to make chatbots their primary customer communication channel by 2027. This is because consumer behavior has shifted to primarily digital interactions and away from traditional customer support channels.

    As a result of today’s digital landscape, consumers are now accustomed to immediate gratification and expect instant responses and resolution from customer support, which makes chatbots an ideal solution for brands to rapidly serve customers. Due to this rising demand for instant customer service, chatbot systems have become more sophisticated and consumers’ reliance on them is increasing. This increase in adoption has led to higher performance expectations for bots and if those expectations are not met, customer satisfaction and brand loyalty will suffer.

    Below, we’ll look at three major challenges tied to the growing popularity of chatbots as they handle larger and more diverse groups of customers, and how business leaders developers and DevOps and customer experience (CX) teams can tackle these common challenges with a continuous testing approach.

    The Pain Points of Adoption: 3 Key Challenges as Chatbot Usage Grows

    As the popularity of chatbots explodes for customers around the world, the underlying systems that handle natural language processing (NLP), latency, data security and other functions need to be stronger. This is due to a growing and increasingly diverse demographic of users, many of whom are sharing more of their personal information to address a wider range of customer needs. Common chatbot pain points can be summarized by three overarching challenges.

    Challenge #1: Chatbots must contend with a larger and more diverse base of customers

    Chatbots that are voice or text-enabled must be smart enough to operate securely while navigating countless variations in spelling, a wide range of spoken accents and vernacular, background noise, static from bad connections and more. Even in a single language, there may typically be only four or five “intents” from most customers in engaging a chatbot, but those intents may be phrased in hundreds of different ways. Now, the global growth in adoption raises the chance of poor connections and exponentially increases the number of languages and variations in phrasing that a chatbot must understand and interpret.

    Challenge #2: Customers are trusting chatbots with more personal and sensitive data

    As chatbots become smarter and more trusted by customers to meet their needs, people are getting more comfortable giving their personal data to chatbots. That increases the number of situations where chatbots are working with personally identifiable information (PII) or other highly sensitive data. Especially given GDPR and other data privacy regulations being enacted worldwide, there’s added pressure to ensure a chatbot system’s handling of this data remains secure and compliant across all use cases and geographic regions.

    Challenge #3: Modern chatbots require 24/7 availability and reliability

    In an era of flexible work and millennial and Gen Z audiences interacting with bots after business hours and on weekends, chatbots can’t afford to work in shifts. Users may be spread across many time zones or around the world, meaning there’s always a sizable portion of customers awake, online and looking for fast and efficient service. Because of this, chatbots must be able to handle spikes and heavy traffic 24/7.

    The executive takeaway from these challenges is that modern chatbot investments must be built around dynamic systems capable of adjusting to shifting customer usage and performance requirements.

    A Continuous Testing Mindset is Required for Top Chatbot Performance

    Fortunately, by honoring a few best practices and making the right strategic technology investments in automated artificial intelligence (AI) and machine learning (ML)-driven systems, C-suite leaders responsible for CX and the teams they manage can deploy chatbots capable of keeping up with the above challenges. Perhaps the most central element for success is to embrace a continuous testing approach.

    For example, when a company is undergoing digital transformation and shifting its contact centers and supporting systems to the cloud, they are moving a significant amount of data, reimagining complex integrations and rearchitecting processes. In order to maintain application stability and existing integrations in the contact center, continuous testing is critical to ensure that an organization’s systems still operate effectively throughout the cloud migration process. With continuous testing, development and testing aren’t separate processes. The testing is automated and quality assurance is involved as developers submit code.

    The most effective approach to continuous testing includes end-to-end analysis across all channels. Testing chatbot behaviors should mimic real-time customer interactions. This should include challenging scenarios such as unexpected user inputs and usage spikes at random times of the day and night. Automation is critical, especially in peak demand scenarios such as Black Friday, Cyber Monday, open enrollment, etc. Load testing up to 1,000-100,000 bot requests per second, or more, can help ensure companies will be able to handle the increased traffic. Ideally, the testing approach should be comprehensive to include automated NLP score testing, conversational flow testing and security testing and performance testing and monitoring.

    By promoting the continuous testing approach across contact center operations, executives can empower their teams to build and maintain chatbots that remain optimized on an ongoing basis and that form an essential part of providing exceptional CX. This will make a huge difference in performance and reliability as systems scale and adapt to the evolving demands of a growing customer base.

    Continuous Testing Elevates Chatbot Reliability and Value

    High-performing chatbots and the continuous testing that keeps them optimized at those performance levels can benefit any company by lowering risks and enhancing revenue. Organizations that become adept at applying continuous testing avoid 90% of the downtime from high-severity (SEV 1) errors, which can result in saving $2.2 million in costs over a three-year period. When continuous testing touches every stage of the development process, it identifies issues earlier and helps strengthen an organization’s ability to innovate faster and service its customers effectively and profitably.

  • Implementing ChatOps Using Open Source Tooling

    Implementing ChatOps Using Open Source Tooling

    ChatOps is an exciting proposition for organizational Ops communication. Throwing development and operational tooling into the chat conversation can ease the development pipeline, increase transparency and increase security by streamlining bug detection and remediation efforts.

    At the heart of ChatOps are bots, scripts and chat clients; many are pre-built and open source. In this article, we’ll review a completely open source method for building out your ChatOps setup. We’ll cover integrating with Hubot, using CoffeeScript commands, and how building custom scripts can ignite ChatOps in your own environment.

    Why Open Source for ChatOps?

    Many arguments have been given as to the benefits of open source. Building upon open source inherently evades vendor lock-in, enabling more security and service longevity. Furthermore, to avoid reinventing the wheel, forking existing open source ChatOps projects naturally will be more efficient than purely greenfield initiatives.

    Open Source Chatbots

    There are many Chatbots available for use; each with unique capabilities, varying types of integrations out of the -box, and different ways to extend functionality with custom scripts. Take Lita, for example, an open source chatbot built with Ruby. It works with IRC, HipChat and Campfire. Many other open source chatbot options exist, such as Errbot, Jarvis and Lazlo.

    Example: Hubot

    By far the most adopted open source ChatOps companion is Hubot. Designed and open sourced by Github, Hubot takes market share in the ChatOps discussion. Described as “a customizable, life betterment robot,” Hubot is written in Node.js and takes commands with CoffeeScript.

    Using Hubot, developers can initiate commands with Hubot scripts to perform actions such as post images, translate languages and integrate with maps, but also initiate vital commands to your favorite DevOps cloud tools. A full catalog of scripts can be found here, and it’s quite easy to craft your own CoffeeScript commands as well.

    Example Hubot Scripts

    The community scripts that support Hubot are similarly open source, meaning that you can repackage these implementations to suit your own needs. Let’s take a look through the catalog of Github-supported Hubot scripts to see what sort of pre-constructed extensions we can seamlessly add to a Hubot environment.

    With Hubot, you can ping your major cloud development platforms, such as Heroku. Some example commands for returning status of issues on Heroku include:


    hubot heroku status - Returns the current Heroku status for app operations and tools

hubot heroku status issues <limit> - Returns a list of recent <limit> issues (default limit is 5)

hubot heroku status issue <id> - Returns a single issue by ID number

    Or perhaps you want to conveniently check PagerDuty from your chat client to see who is on call within your incident response team, or to gather details on current incidents. Hubout has a script for that. Using pagerduty.coffee, some example requests might be:


    hubot who's on call - return the username of who's on call

hubot pager me trigger <msg> - create a new incident with <msg>

hubot pager me incidents - return the current incidents

hubot pager me notes <incident> - show notes for incident #<incident>

hubot pager me problems - return all open incidents

    Another example could be direct interaction with the Twilio API for sending SMS. Using sms.coffee you can initiate a command with the following syntax:


    hubot sms <to> <message> - Sends <message> to the number <to>

    Configuring sms.coffee is easy, all you need to insert are:


    HUBOT_SMS_SID

HUBOT_SMS_TOKEN

HUBOT_SMS_FROM

    Of course, there is no shortage of Gifs, cat memes, and other scripts to add some humor to your workday, such as mustache insertion using image detection.

    Generating Your Own Hubot Scripts

    Aside from using third party scripts, you can always craft your own. To be an executable Hubot script, your code must be in .coffee or .js, and it must be in the correct directory (src/scripts and scripts by default). It must also export a function, as in the following:


    module.exports = (robot) ->

# your code here

    Essentially, Hubot listens to all chat communication; it will hear commands and respond accordingly. To configure what it must hear in regards to your script, you must specify what to listen for, and what to respond with. For example:


    module.exports = (robot) ->

robot.hear /badger/i, (res) ->

# your code here

robot.respond /open the pod bay doors/i, (res) ->

# your code here

    For further details, see the documentation on Scripting here.

    Getting The Most of Chatbots

    Once integrated into a chat platform such as Slack, your chatbot configuration can truly thrive. Given the wide breadth of community generated and Github-maintained scripts, DevOps teams have near unlimited potential for uniting their tooling into a single, human-readable CLI. Another benefit of choosing open source tools for such projects is that you can detach your bot and integrate with whatever chat client you prefer.

    ChatOps can add fun and efficiency to the remote workspace. We’ve covered high-level methods for adopting this into your team’s space, and hopefully, a helpful foundation into the power of open source for streamlining the power of ChatOps.

    — Bill Doerrfeld

  • Automation, ChatBots Can Improve DevOps

    Automation, ChatBots Can Improve DevOps

    At its heart, the goal of DevOps is to foster better communication between the development team and operations team at an organization. When these two teams are systematically connected, they can easily stay in sync on most issues and there is strong coordination in building and delivering the product to customers.

    Automation and ChatBots can play a big role in the connecting development and operations. They open the door for companies to go beyond simply being alerted when something happens in a chat application, allowing an employee to take action after receiving the alert either in an automated manner or by providing guidance to the employee on which actions to take.

    Automation: Creating Smart Alerts That Don’t Require Follow-Up

    Monitoring applications, systems, virtual machines and networks are a key part of any operations team. There are a number of tools that are used for this purpose, including CloudWatch, Splunk, Rollbar, Pingdom and Newrelic. These tools typically alert the operations teams when there are issues. Engineering teams, on the other hand, use tools such as JIRA and Github to track tickets and manage their agile development process. Alerts from the tools used by operations are helpful, but they still require some manual follow-up. For example, imagine a critical alert is reported by one of the tools because of a product issue. Follow up on this alert would require:

    • Creating a ticket in JIRA/Github with all the relevant information to help diagnose the issue.
    • Escalating that ticket so that it gets looked into right away.
    • Keeping the required people in sync as the status of the issue changes.

    This entire process can be automated. When automated, the workflow operates like this:

    • When the monitoring tool senses there’s something abnormal, like error rates above certain thresholds or a critical failure, alerts are sent and a ticket is created in JIRA or Github automatically with all the relevant information about the issue.
    • Taking this a step further, based on the type of issue, it can be automatically assigned to the right person and even post a message on the appropriate Slack channel.
    • As engineering works through the issue, everyone is automatically informed in Slack when the ticket is updated.

    The key to getting this scenario automated is to leverage an integration and automation platform that is powerful enough to handle complex workflows, yet easy to use so that these automations can be built in minutes. Users don’t want to work for your automations, they want their automations to work for them. With that in mind, the platform should also be flexible so changes can be made to the workflows without any engineering effort (i.e., an automation platform where integrations and automations can be built and changed without any coding).

    ChatOps: Monitor and Orchestrate via Chat Platforms

    With all the apps being used by DevOps, it is difficult for any team to stay on top of monitoring and managing issues while also taking actions across all these tools. Studies show that app hopping is not efficient and results in constant context switching, which negatively impacts productivity.

    ChatOps allows users to stay on top of everything including orchestrating workflows right from chat platforms such as Slack. To make ChatOps work, users need a bot that works in tandem with an integration and automation platform. The bot works with all business apps (even the tough ones with custom objects such as Github and Salesforce), is customized to meet the specific needs of the business and can extend to address all operational needs.

    Here are three ways users can leverage bots for better DevOps:

    Smart, actionable alerts: Rather than have a firehose of alerts coming in, users can define various thresholds, monitor velocity of alerts and, based on these settings, post an alert to the relevant channel or person on Slack. Bots can also prompt the person to take action based on the notification.

    Stop services, virtual machines: Bots can connect with any app, or service that has a HTTP/REST API. Not only can they monitor various apps and environments, they also can start and stop them.

    Workflow orchestration: Various workflows such as managing incidents, escalations and deploying code are all triggered and managed through Slack.

    Automating DevOps has significant benefits in overall increased engineering and operations productivity. The key to automation success is to select an integration and automation platform that is secure, resilient, can handle complex workflows, can be easily customized to meet the specific needs of the business and can be managed through Slack. It should be easy to use so automations can be built fast and changed easily as workflows change. Automation and ChatOps will streamline business workflow, keep the important players from both development and operations informed and increase productivity for everyone involved.

    About the Author / Gautham Viswanathan

    Gautham Viswanathan is the founder/head of products at Workato, www.workato.com. He also leads the team in creating Workbot For Slack, a bot designed to be customizable and allow you to do work in your apps right from Slack. Gautham has a deep background in integration platforms and was previously the head of products and engineering at TIBCO. Connect with him on LinkedIn.