 Hello everyone. I would like to talk about automation with Python and the way we found to share this automation within the company. After several iterations, we found the way I will speak about. Before we start, I want to narrow the area. We will consider mainly operational tasks, which are routine in most cases. The tasks like to support infrastructure, to work with customer issues, to work with incidents, and other operational tasks, so not development, not programming. Let's start. At first, whom we will speak about here on the screen, you see the employees of the company, and these employees experienced in some subject area and able to write the automation screens of their routine part of work. But let's see why these experts should work with certain routine tasks. They have access to some applications for some software. They in charge of the software. Access to some databases, some network access, access to some APIs, and sure they have knowledge of how to interpret data, and what to do with this data. So let's consider the idea. What if experts create a virtual assistant for themselves? They can equip his workplace as their own with the same access to applications, to databases, and so on. And they can transfer their routine tasks to the assistant. This will free up experts' time for new not routine tasks and will save time of tasks processing. Although there are barriers, programming a virtual assistant in itself requires additional expertise, time, and costs. Let's see. We will consider in my talk how we can solve these barriers. Let's continue. In this slide, I want to discuss what are the routine of operating activities for IT specialists? What is usual routine? Getting, changing attributes of an entity. The simplest example of an entity is your user, for example, the user in database, anywhere. The next point, collection, analysis of logs. Configuring systems. It can be very routine tasks. Incident response. You need to give a response fast. Maybe you need to reconfigure a few servers to respond to this incident, and you need to do it fast. Here, let's consider first step of automation. At the beginning, at first, routine actions are performed manually using web interfaces of systems, client applications of systems, SQL clients, API clients, SSH clients, whatever, to access the system and to solve the problem, to reconfigure the system, to get the data from database, to change the configuration, and so on. Then, to save time, employees automate their tasks using a high level, let's say automation-friendly, language like Python. Another example can be shell script, for example. But Python is very popular for such tasks, for tasks to automate some routine work. However, it is still a specific employee who runs and maintains the automation scripts, because probably you can guess, I think you know that it's hard to share the automation scripts, because you cannot share your network accesses. You cannot share your logins, your passwords. You even cannot share the scripts with somebody who not experienced with the Python, with the systems. And you also need to share environment for the scripts. It's hard to share such scripts. And before I will tell you our solution, let's check these options. What are the usual options to exclude our experts from routine processes? Let's say it's usual, it's the right way, but this way is an expensive way. Integrate routine interfaces available to other employees. For example, client relationship management system, or some system to orchestrate your servers, your containers, services, whatever. But this interface, there are many such interfaces usually in a company. And one interface will be not enough, because there are many tasks. And there are many different groups in company, teams in company with the different tasks, with the different software available in this company, with the different interfaces. And you will need time for sure, money for this development. You will need analysts and developers. And the speed of implementation of change will be usually not the best, not the very fast for this case. Another options. Give access to your interfaces. Sure, it's dangerous. I think we will not stop here in details why it's dangerous. And it requires training. And Routine did not go away. We just shifted it to others. We just relaxed our experts, but other still will do this Routine. Next options. Pass your automation script to others. Again, it's dangerous. Accesses, logins, password, environments, and so on. And the other people need the competence. So these two options is, it's unacceptable. The last options, the last options, develop a single interface for systems that are managed by a group of experts. For example, the group of experts who is in charge of the databases, they can develop or some APIs, they can develop the web interface or chatbot or even API to access to their systems for their colleagues. And through this interface, the colleagues can run some automation scripts, get the results, apply some changes, reroute traffic, for example, they get the attributes of user and so on. But this requires additional expertise from experts. They usually are experts in their systems. And they don't know, the most of them maybe don't know how to use chatbots, how to implement web interface, how to implement APIs, and so on. So they need to spend the time for this or they need to ask other colleagues to do it. But we choose these options, these options, and we removed the cons. And I will explain you our solution. So, we developed a platform, a platform for publishing automation scripts within a company, and we published that platform in Python package index, so it's available for all of you. Let's see how to use it. We can take a server, make the necessary network accesses for it, create credentials in the necessary systems. So it's like on that slide, the virtual assistant, we equip the workplace similar to our workplace for this virtual assistant. Install the platform. We call it skill publishing. On the server, create a user board in the corporate messenger, Slack, for example. As I know, this Slack is the most popular corporate messenger. And give it to the platform. We will see how to give it on next slides. Then the magic happens. Any the star, any, we will talk about the star letter. Any script, we can call it skill. In a high level language, Python can be used in the platform without adaptation. Without adaptation, it's like a magic, yes. The platform itself will integrate the script with the messenger and JSON API. Provide access control, monitoring, logging, the outer of the script only determines who can use the skill. So who can access the skill. So let's see how it works with the examples. On this slide, you see the configuration, JSON. That's only one config file for the platform. And here you see the channels. For our example, I used two channels, Telegram, the other popular messenger and Slack. And we only put the tokens here. And the tokens is enough for platform to communicate with the messenger. And we add one user, James. James use channels, Slack and Telegram. And here is a username in Slack and ID in Telegram. So James has access to the platform through Slack and Telegram. And here is a hello world script for the platform. Just print. We use hello from outer space. And you see the script has nothing about the communication with the Slack or with the Telegram. It's just a print. It's a usual Python script. And you see that James can run the script from the Slack and receive the result. He can see the print. The same in Telegram. All these scripts in folder skills can be run such way. Let's see another example from real life. I'm a solution architect in Russian Telecom operator. And this is a very usual case when I need to get some user profiles, subscriber our subscriber profile from the repository. One of our software model. And there were many cases for me at the beginning when we started our network, when we started our service for me. Please check this subscriber. What's wrong with his profile? Please update the profile and so on. And I cannot give access to support engineers to this server. And to move this data to other systems like billing, like client relationship management. We need time. We need integration and so on. Of course, we do it. But we do it step by step. But I need response. I need faster response for big number of support requests. So I did the one of the first automation. It's code like this. The pure Python code. Where we get the parameters. You see these parameters. It's me in Russian. Sorry. I call the scripts. And I gave the parameters to the scripts, the phone number. And I used these parameters in script. The usual way. The same when we run the script in shell. Then I use this number in the script. I connect to the subscriber profile repository, get the data and print the data. So it's simple, but it was useful in our work. Of course, this script now has many other functions like update the profile and other things to do with the subscriber. Let's see other examples. Do you remember the star near to any script? Some scripts can be adopted for the platform. And here we see the example how script can be adopted for the platform. You can use the structures like this. Print and the Python dictionary. It's a usual structure. Dictionary. Just print buttons and the names of the buttons. And you will see in select the buttons and in telegram you will see the same buttons. And then you can input the data. The usual for Python way. Input the data from the user. And the user will print one of the bad button and you will get the text from the button. Okay, let's continue. More features. Displaying images. This script isn't adopted for the platform. It's common script. You see it's a library. It's Python library for showing the image. And here we get the image from Wikipedia. Get the image of the space station. And just show this image. And you will see the image in Slack. This simple example maybe looks like we are playing. We just have fun. But it's very usual in operational useful in operational work. For example, I am responsible for some part of the network. I am at home at night. Somebody from support team call me. Ask me. There is an incident. We need to solve it. We need your support. You are responsible for the part of the network. We already did all we can. So I just, before I wake up and get my notebook, I can push the buttons in Slack. And I can get all the important images from our monitoring system, like Grafana or Zabix. And you can imagine that on this picture, not the space station, but your traffic on your servers, your users' requests. And they goes down. And you need to do something. And in 10 seconds, you already see the most important pictures. And probably you already know what to do. Maybe you will do it. You will run another script you have on the platform. And you will reroute the traffic. You will reboot the servers and so on. You will make an action. So, more features. More features you can find on the Internet, on the GitHub. You can search in Google, SkillPub, GitHub, and you will find this page. For example, you can print the file, some other features. I will only tell you maybe that not all the features are described here. I'm working on this. But now the platform has many new functions. I will describe it. For example, recently we had the possibility to share the request from Slack for multi-instance of the platform. So you can launch the multi-instance reliable platform and balance the load for this platform. But later, if you are in interest with the platform, you will find it here. So let's continue. I think I have just a few this one more slide. How we use it in customer service. So customer service is a business process. And on this slide, you see the usual, I think, the process how to solve customer's issues. The first-level support. The guys who work in first-level support use knowledge base and use client relationship management, usually these two systems. And if they cannot solve the problem, they send the ticket to second-level support. Second-level support use various tools, additional to client relationship management. And these tools are connected to the network to our servers, services, databases, APIs, and so on. And if the second-level support cannot solve the problem, they send the ticket to subject matter experts. And these guys, I am one of these guys, use the platform, SkillPub, to automate their rotine tasks. The tasks related to the support, for example, it is just one example of such tasks. And they can give the skills, give the automated skills to the second-level support. And second-level support when they will have the same ticket with the similar problem, they will just run the script through the Slack and have the result. So that's probably all for this. And I think that this one is lost. More use cases. Just to note some other cases, maybe repeat some cases. We use it, the platform. And this way to share automated scripts, we use to fetch some diagnostic information from multiple data sources into Slack. Gather metrics, logs, and analyze them. To take action in case of incident right from chat up, rerouting user requests, server rebooting, launching new instances, and many other actions. To give easy access to APIs via chat up, 14 members and other colleagues. To provide analytical reports, this one is very popular, buy the request from chat up, reports with graphs, images, tables, files, etc. So I think I'm done. And this one, this is just a thank you, Python community. So thank you for everything. So we have a few minutes. So we can read two questions. So let me check that. I can see the questions. Can Slack Skype be replaced with the messengers such as TISCO jubber? Now we support two messengers, Telegram and Slack, but we plan to add other messengers. In company I work in, we use only two. We use Slack and Telegram. But to develop the platform, we have plans to add some other popular messengers. Is there a chance to self host us? Sorry, the question was, I see. Is there a chance to self host a Slack alternative that works with SkillPub? So now the alternative for Slack. Slack is not self-hosted. It's impossible for Slack. So we need to integrate other messengers. But probably we will do it in the future. So in the future, you will have such chance. But now you have other option to use the Json API. The SkillPub will build the Json API for the scripts and you can run it instead of messengers. This is one more option. The next one. Are there best practices for managing credentials with SkillPub? Hard coded in the scripts. It's hard coded in the scripts. But you can access this config file. And we already do it. Now we're on our way to integrate our platform with company service desk software. So the people will request access in service desk. Service desk will notify us and we will add, if the request was approved, we will add the user to our platform. We will do it. And it's already easy to do if you will just integrate with the config file. It's simple Json. So you can access it and you can add users. What to do in case of an outage with telegram slack or bot? So in case of outage, you will not able to access the platform. If you will not have the other, for example, API, if you use the API, it will still work. For example, for us, we have our security engineers, security team approved only slack for our usual work. But for the case when slack in outage, we can switch on telegram. So this is our, how to say the second option. Where do the scripts leave? And how are they connected to our slack workspace? The scripts leave on your server. They are just like in file system in your server. And the connection with the slack only through the platform. Platform connect to slack. Get the request from the slack. They then check the access of this person. If this person have access to the platform and to the script. So the platform run the script and run it locally. Sure, locally on your server. Run it locally. Get the result of this script and send it back to the slack. Okay, cool. Thank you very much. Thank you. If anyone wants to continue the discussion with Anton, you can do that in this corner. You can find him there. There is a channel for this talk in particular and you can also find him in the Brian track. So thank you very much. Have a good day. Thank you. Thank you. Bye.